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EXECUTIVE  SUMMARY 

i < J- 


f re 


The^, object ivej^of  Phase  I of  theXjechnical  Analysis  of  the 
Navy  Manpower  Planning  System  (NAMPS)  was'-^tc 


;o  develop  an  "operat- 


ing scenario*  for  NAMPS,  review  recent  and  on-going  efforts 
supporting  NAMPS  development,  determine  the  general  ADP  require- 
ments for  supporting  the  •operating  scenario,*  and  identify 
subsequent  phases  of  the  Technical  Analysis.  The  ultimate 
objective  of  the  series  of  studies  that  will  make  up  the 
Technical  Analysis  of  NAMPS  is  to  define  overall  ADP  require- 
ments for  NAMPS,  identify  the  shortfalls  of  current  plans  for 
developing  the  required  support,  and  determine  the  feasibility 
of  developing  those  applications. 


An  "operating  scenario"  for  NAMPS  is  presented  which 
describes,  in  narrative  form,  a hypothetical  environment  wherein 
ADP  applications  developed  for  NAMPS  are  used  to  generate  viable 
manpower  requirements  for  the  Navy  programs  contained  in  the 
Program  Objectives  Memorandum ,( POM) . General  characteristics 
and  categories  of  ADP  support"Tieeded  by  the  "operating  scenario" 
are  established  and  those  ADP  requirements  currently  identified, 
for  development  under  CNOCOM/MIS  are  described.  NAMPS  develop- 
mental efforts  undertaken  and/or  completed  since  the  1974  study 
of  CNOCOM/MIS  support  for  NAMPS,  NAVCOSSACT  Document  No.  53D109, 
TR-01  are  reviewed  and  evaluated.  Finally,  chose  portions  of 
the  NAMPS  concepts  which  require  further  study  are  identified. 


The  findings  of  Phase  I of  the  Technical  Analysis  are  that 
methodologies  for  a number  of  concepts  embodied  in  the  NAMPS 
philosophy  have  not  been  developed  to  the  degree  necessary  for 
efficient,  cost-effective  implementation  of  ADP  support.  Anal- 
ysis also  indicates  that  there  are  questions  concerning  the 
technical  coordination  of  NAMPS  ADP  development  which  need  to 
be  resolved.  The  report  recommends  that  each  of  these  problem 
areas  be  studied,  but  it  refrains  from  attempting  to  establish 
a chronology  for  such  studies  in  deference  to  the  prerogatives 
of  the  Manpower  Analysis  & Systems  Development  Branch  (Op-121) . 
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SECTION  1 


INTRODUCTION 


1.1  Purpose.  The  purpose  of  this  report  is  to  document  the 
results  of  Phase  I of  a technical  analysis  of  the  Automated  Data 
Processing  (ADP)  support  to  be  provided  for  the  Navy  Manpower 
Planning  System  (NAMPS)  under  the  egis  of  the  Chief  of  Naval 
Operations  Command/Management  Information  System  (CNOCOM/MIS) . 

1;2  References.  The  project  request  setting  forth  the  objective 
of  and  requirements  for  this  report  (Appendix  A)  was  forwarded  as 
enclosure  (1)  to  CNO  letter  serial  913D3/583701  of  17  February 
1976,  subject:  CNOCOM/MIS  Project  Request;  forwarding  of.  This 
report  assumes  that  readers  are  familiar  with  a prior  report 
dealing  with  the  subject  matter,  NAVCOSSACT  Document  Number 
53D109,  TR-01,  September  1974,  “CNOCOM/MIS  Support  for  the  Navy 
Manpower  Planning  System  (NAMPS)".  Documents  used  for  reference 
and  background  and  cited  in  the  body  of  this  report  are  listed  in 
Appendix  B;  a glossary  of  terms  and  acronyms  is  included  as 
Appendix  C. 

1.3  Study  Objectives.  This  report  documents  the  results  of  the 
first  phase  of  a series  of  study  efforts  intended  to  determine 
what  ADP  applications  will  be  needed  to  support  the  "operating 
scenario"  for  NAMPS;  the  feasibility  of  developing  those 
applications  which  should  be  developed  under  the  egis  of 
CNOCOM/MIS;  and  what  shortfalls,  if  any,  exist  in  current  plans 
for  developing  ADP  support  for  NAMPS.  The  objective  of  Phase  I 
of  this  tecnnical  analysis  was  to  determine  wnat  the  subsequent 
phases  of  the  study  effort  should  be,  based  on  a review  and 
analysis  of  NAMPS  concepts  and  philosophies,  the  contemplated 
“operating  scenario"  for  NAMPS,  and  recent  and  current  efforts  in 
the  manpower  planning  area. 

1;4~  Phase  1 1 • Limitations . Concurrently  with  the  development  of 
this  study,  a separate  effort  directed  to  the  justification  of 
NAMPS  as  a separate  Automated  Data  System  (ADS)  was  also  under 
way  by  a contractor  working  for  Op-121.  In  addition, 
negotiations  between  Op-01  and  the  Bureau  of  Naval  Personnel 
(BuPers)  were  addressing  the  use  of  the  BuPers  computer  site  as  a 
possible  location  for  the  major  portion  of  the  NAMPS  ADP  support. 
In  view  of  these  developments,  certain  aspects  of  the  NAVCOSSACT 
study  have  been  curtailed  in  order  to  avoid  possible  conflicts  of 
interest  with  other  agencies  which  might,  in  the  future,  become 
major  developers  of  ADP  support  for  NAMPS.  Consequently,  this 
report  does  not  completely  satisfy  the  requirements  of  the  study 
request  (Appendix  A)  in  that  descriptions  of  ADP  requirements  in 


3 


SECTION  2.  THE  NAMPS  CONCEPTS 


The  genesis  of  NAMPS,  the  reasons  for  its  development,  its 
basic  philosophies  and  its  basic  structural  design  have  all  been 
set  forth  in  an  earlier  report.!  This  section  contains  a review 
of  the  NAMPS  structural  design  and  a "scenario"  describing  a 
logical  sequence  of  events  that  would  take  place  once  all  of  the 
required  modules  and  ADP  support  for  NAMPS  become  available. 

2;1*  The -NAMPS  Structure.  NAMPS  has  been  planned  as  a series  of 
twelve  interactive  and  Interdependent  "modules"  or  "nodes" 
representing  the  ma]or  functions  of  the  NAMPS  concept  (Figure 
2-01).  Conceptually,  NAMPS  proposes  that  manpower  requirements 
for  the  Navy  be  derived  from  statements  of  operational  and 
support  capabilities  that  are  needed  to  attain  a stated  or  given 
operational  posture. 2 These  statements  of  operational  and 
support  needs  are  to  be  defined  as  Required  Operational 
Capabilities  (ROCs) , for  fleet  units,  and  as  Required  Functional 
Capabilities  (RFCs) , for  elements  of  the  Shore  Establishment. 
Within  the  framework  of  the  Operational  Requirements/Productive 
Capacity  Module  of  NAMPS,  planners  and  sponsors  will  adjust  their 
statements  of  operational  requirements  rather  than  applying 
increments  or  decrements  of  manpower  to  previous  statements  of 
manpower  needs,  as  is  done  currently.  At  the  same  time,  the 
impact  of  changes  to  operational  neeas  will  automatically  be 
reflected  in  concomitant  changes  in  support  requirements .3 

The  staffing  standards  and  algorithms  for  applying  them  to 
ROCs  and  RFCs  would  fall  within  the  framework  of  the  Manpower 
Reference  Model  and  would  be  developed  from  existing  manpower 
documentation  programs.1 2 3 4  The  requirements  for  these  data  bases 
include  accessibility  (by  OPNAV  planners)  and  adaptability  (to 
dynamic  modifications  of  ROCs  and  RFCs) ,5 


1 NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974. 
“CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS) ” . 

2 Ibid,  p 7 et  secj 

3 Ibid,  p 38  etseq 

4 Ibid,  pp  8,  26 

5 Ibid,  p 74  et  seq 
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FIGURE  2-01.  The  Basic  NAMPS  Structure 
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The  mechanisms  that  match  operational  and  support 
requirements  (in  terms  of  ROCs  and  RFCs)  to  manpower  reference 
data  (in  terms  of  billets  needed)  , aggregate  the  basic  manpower 
needs,  and  determine  rough  costs  are  incorporated  within  the 
framework  of  the  Manpower  Determination  Model.  This  module  must 
be  able  to  cope  with  various  levels  of  data  aggregation,  from  the 
level  of  the  individual  unit  or  activity  to  the  overall 
requirements  of  the  entire  Navy.6 

Once  the  basic  manpower  needs  have  been  ascertained,  factors 
representing  the  impacts  of  technological  improvements 
(maintained  in  the  Technology/Productivity  Measurement  Model)  and 
factors  representing  impacts  of  changes  in  the  Navy's  physical 
plant  ashore  (maintained  in  the  Facilities  Expansion  Model)  would 
be  applied  within  the  framework  of  the  Projected  Manpower 
Requirements  Module.7  The  output  of  this  process  is  then  used  by 
the  Personnel  Inventory  Analysis  Module  to  determine  how  well  the 
projected  personnel  inventory  (officer,  enlisted,  civilian)  will 
satisfy  the  projected  manpower  requirements.^  Part  of  the 
analysis  of  personnel  inventory  vs  manpower  requirements  would 
cover  the  requirements  for  recruitment  and  training  and  the 
impact  of  attrition  and  other  personnel  losses  (Inputs  Required 
Model,  Training  Required  Model,  Losses  Requited  (Expected) 

Model)  . 

If  any  of  the  analytical  processes  disclose  unmanageable 
disparities,  significant  overages  or  shortfalls,  or  other  results 
implying  that  the  array  of  manpower  requirements  is  not  feasible, 
“feedback"  data  indicating  the  nature  of  the  infeasibil  ties 
would  be  collected  (Feedback  Constraint  Controls)  and  used  as 
input  (together  with  the  original  set  of  data)  to  the  Alternative 
Generator  Model  for  the  purpose  of  generating  alternative 
operational  requirements  that  would  be  feasible  from  the 
viewpoints  of  manpower,  personnel  and  training. 9 

2:2’ -A- ^Scenario* ' for  Using  NAMPS  ADP  Support.  While  the  prior 
report  on  NAMPS  discussed  at  some  length  the  genesis  of  NAMPS, 
its  approaches,  and  the  various  manpower  planning  problems  which 
\ motivated  its  development  as  a concept,  very  little  was  included 


6 

Ibid , 

PP 

44, 

45 

7 

Ibid , 

PP 

4 5- 

49 

8 

Ibid, 

PP 

10, 

53-61 

9 

Ibid , 

PP 

11, 

52 

7 


r 


about  the  practical  aspects  of  how  NAMPS  and  its  ADP  support 
would  be  used  by  OPNAV.  An  examination  of  the  manpower  planning 
problems  previously  itemized^  reveals  that  most  are  associated 
with  the  programming  phase  of  the  Department  of  Defense  (DOD) 
Planning,  Programming  and  Budgeting  System  (PPBS).  The  primary 
process  executed  by  the  Navy  during  this  phase  is  the  development 
of  the  Program  Objectives  Memorandum  (POM) , a process  also 
discussed  at  some  length  in  the  prior  report. I1  By  implication, 
then,  the  primary  utility  for  NAMPS  will  be  in  support  of  the 
"POM  process'*;  and  to  be  successful  in  its  goals,  NAMPS  must 
incorporate  automated  methodologies  that  will  be  viable  in  the 
changing  environment  of  the  "POM  process",  operate  easily, 
safeguard  the  confidentiality  of  data  involved  in  that  process, 
and  still  be  responsive  to  the  needs  of  the  NAMPS  users. 

2.2.1  The  "POM  Environment".  The  term  "POM  environment"  is  used 
to  identify  the  atmosphere  of  guidance  documents,  assignment  of 
responsibilities,  interdependent  relationships  between  OPNAV 
offices  having  different  and  parochial  concerns,  and  the  constant 
pressures  of  deadlines,  due  dates,  and  almost  continual 
interactions  with  persons  and  offices  at  all  planning/programming 
levels.  The  term  "POM  process"  is  usea  to  identify  the  sequence 
of  events  that  transpire  during  the  development  of  the  POM. 

The  "POM  process"  and  “POM  environment"  tor  development  of 
the  POM  for  fiscal  year  1976  (POM-76)  were  described  briefly  in 
the  prior  report,  as  were  changes  proposed  for  POM-77. 12 
Procedures  used  for  manpower  planning  during  POM-77,  as  well  as 
modifications  of  those  procedures  used  during  POM-78,  will  be 
discussed  in  another  section  of  this  report,  however,  certain 
aspects  of  the  "POM  environment"  for  POM-78  need  to  be  presentee 
in  this  section  in  order  to  set  the  stage  properly  for  the  NAMPS 
“operating  scenario". 

The  tentative  schedule  for  POM-78  covered  a period  of  time 
from  3 September  1975  to  mid-May  1976.13  Critical  dates  on  this 
schedule  included  issuance  of  CNO  Policy  and  Planning  Guidance 


10 

Ibid,  pp 

4-6 

11 

Ibid,  pp 

30-34 

12 

Ibid,  pp 

30-34 

13 

Op-901  memo  of  2 SeD  1975,  POM-78-1,  ser 
"Program  Objective  Memorandum  Procedures 

901/52352, 
for  FY-78 

enclosure  (1) . 


subject: 
(POM-78) " , 
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(CPPG)  on  15  Octooer;  presentation  ot  CNO  Program  Analysis 
Memoranda  (CPAMs)  beginning  9 January  19/6;  Secretary  of  the  Navy 
(SLCNAV)  guidance  issued  21  January  1976;  presentations  by 
platform  sponsors  beginning  11  February;  issuance  ot  CNO  Program 
and  Fiscal  Guidance  (CPFG)  on  25  February;  presentation  of 
Sponsors  Program  Proposals  (SPPs)  commencing  1 March; 
finalization  ot  the  summary  CPAM  by  30  March;  and  presentation  of 
the  tentative  t'OM  (i-FOM)  to  SECNAV  on  1 May,  with  submission  ot 
the  POM  to  the  Secretary  of  Defense  (SECDEF)  on  or  about  15  May. 

Of  more  significance  to  this  discussion,  however,  is  the 
summary  of  sponsor  assignments  and  responsibilities  for  POM-78. 
Three  types  of  sponsors  were  identified; 

a.  Mission  Sponsors (Figure  2-02).  A Mission  Sponsor  was 

defined  as  "a  DCNO'  or  'dT  rec  tor  ofa'  Major  Staff  Office  (DMSO) 
charged  with  responsibility  for  developing  overall  goals, 
objectives,  rationale,  justification  and  resource  requirements 
(including  manpower,  support  and  training)  tor  a specified 
mission  area." 

b.  Resource  Sponsor  s_  (Fig_ure_  2-03)  . A Resource  Sponsor, 
also  refer  re<T  to ""as*  a Fbr'ce/Functio'n  Sponsor  , was  defined  as  “a 
DCNO  or  DMSO  responsible  for  an  identifiable  aggregation  of 
resources  wnich  constitute  inputs  to  mission  accomplishments. 

His  responsibility  covers  interrelated  programs  or  parts  of 
programs  found  in  several  mission  areas."  Resource  Sponsors 
include  Platform  (formerly  called  warfare)  Sponsors  and  sponsors 
of  other  types  of  resources. 

c.  Appropr iation  Sponsors  (£_igure_  2-04)  . An  Appropriation 
Sponsor  was  defined  as  "a  DCNO  or  DMSO  charged  with  supervisory 
control  over  an  appropriation." 

Although  not  specifically  included  as  participants  in  the 
"POM  process”,  two  other  types  of  sponsors  should  be  identified 
for  future  reference.  Program  Sponsors  and  Program  Element 
Sponsors.  A Program  Sponsor  is  defined  as  "the  DCNO  or  Director 
of  a Major  Staff  Office  who,  by  organization  charter,  is 
responsible  for  determining  program  objectives,  time-phasing  and 
support  requirements,  and  for  appraising  progress,  readiness,  and 
military  worth  for  a given  weapon  system,  function  or  task”; 
while  a Program  Element  Sponsor  is  defined  as  "the  DCNO  or 
Director  of  a Major  Staff  Office  responsible  for  force 


14  Ibid,  enclosure  (2)  . 
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Navy  Mission  and  Mission  Su 


Mission  Areas 


Strategic 

Sea  Control  (Overall) 

Ocean  Surveillance 

Area  Anti-Submarine  Warfare  (ASW(A)) 
Local  Anti-Submarine  Warfare  (ASW(L)) 
Surf ace- to-Air  Warfare  (AAW) 
Anti-Ship  Missile  Defense  (ASMD) 

Air- to-Air  Warfare  (AAW) 

Anti-Surface  Warfare  (ASUW) 

Projection 

CV/Air  Strike  Forces 
Amphibious;  Mine;  Special  Warfare 

Fleet  Support 

Mobility  Forces 

Mission  Support  Areas 

C3  and  Intelligence 

Intelligence 

Command  & Control  & Communications 
CCP 


Op- 06 

Op-095 

Op-095 
Op-095 
Op- 03 
Op-03 
Op- 03 
Op- 05 
Op- 03 


Op- 05 
Op- 03 

Op- 03 

Op- 04 


Dp-009 

Op-094 


General  Support  & Logistics 

Support  and  Logistics 
Shore  Command 
R&D  Support 

Support  to  Other  Nations 

Manpower  and  Training 

. Medical  Support 
Training 

Personnel  Support 


Op-04 
Op-09B 
Op-09B 
Op- 06 


Op- 04 
Op-099 
Op- 01 


FIGURE  2-02.  Mission  Sponsors  for  POM-78 


10 


Resource  Areas 


Sponsors 


Platforms 

Surface  Warfare  Op- 03 

Submarine  Warfare  Op-02 

Air  Warfare  0p-05 

Other  Resources 

Command  & Control  & Communications  Op-094 

Ocean  Surveillance  Op-095 

Manpower  Op-01 

Logistics  Op-04 

Command/Administration  Op-09B 

Research  & Development  Op-09B 

Training  Op- 099 

Military  Assistance  Op-06 


FIGURE  2-03.  Resource  Sponsors  for  POM-78 
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Appropriations 


Sponsors 


Ship  Construction,  Navy  (SCN)  Op-03 

Aircraft  Procurement,  Navy  (APN)  Op-05 

* Other  Procurement,  Navy  (OPN)  Op-04 

* Weapons  Procurement,  Navy  (WPN)  Op-03 

Research,  Development,  Test  & Evaluation  (RDT&E)  Op-098 
Military  Construction  (MILCON)  Op-04 

Operations  & Maintenance,  Navy  (O&MN)  Op-92 

Military  Pay,  Navy  (MPN)  CHNAVPERS 

Military  Construction,  Naval  Reserve  (MCNR)  Op-09R 

* Reserve  Pay,  Navy  (RPN)  Op-09R 

* Operations  & Maintenance,  Naval  Reserve  (O&MNR)  Op-09R 


* Op-92  acts  as  cognizant  office  for  POM  coordination. 


FIGURE  2-04.  Appropriation  Sponsors  for  POM-78 
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composition,  funding  support,  and  programmed  manpower  for  a 
specific  program  element". 15 

The  significance  of  the  sponsorship  identifications  lies  in 
the  interdependency  of  the  different  types  of  sponsors.  For 
example,  sponsorship  of  the  Sea  Control  mission  rests  with  Op-095 
who,  by  implication,  levies  resource  requirements  on  several 
different  Resource  Sponsors.  Conversely,  Op-03,  as  a Resource 
Sponsor,  must  support  several  different  mission  areas.  For  the 
purposes  of  the  NAMPS  scenario,  it  is  assumed  that  responsibility 
for  developing  resources  for  each  different  mission  area  is 
delegated  to  separate  offices  under  each  Resource  Sponsor  and 
that  NAMPS  is  concerned  only  with  those  resources  which  levy  a 
workload  requirement  that  must  be  satisfied  with  appropriate 
manpower . 

2.2.2  How  NAMPS  will  be  Used.  When  all  NAMPS  modules  and  all 
required  AbP  support  have  been  fully  implemented,  there  will 
exist  a Navy  Manpower  Planning  System  that  will  be  rapidly 
responsive  to  changing  operational  requirements,  providing  OPNAV 
planners  with  almost  instantaneous  assessments  of  the  manpower 
impacts  of  changes  in  operational  requirements;  alerting 
personnel  planners  to  changes  that  will  be  needed  in  recruitment, 
training,  advancement,  and  release  programs  to  cope  with  changes 
in  manpower  requirements;  identifying  problem  areas  that  may 
develop  should  certain  proposed  changes  in  operational 
requirements  be  allowed  to  take  place;  developing  alternative 
proposals  for  operational  changes  with  which  manpower  and 
personnel  planners  can  more  easily  cope;  and  ultimately  providing 
data  about  approved  changes  in  manpower  requirements  in  a format 
that  will  permit  rapid  updates  of  manpower  documentation  and 
authorization  files. 

Based  on  the  description  of  the  "POM  environment"  discussed 
in  preceding  paragraphs  (2.2.1  above)  and  on  the  fact  that  the 
primary  usefulness  of  NAMPS  will  be  in  the  support  it  provides  to 
manpower  planners  during  the  "POM  process",  the  "operating 
scenario"  that  will  be  followed  can  be  postulated  as  transpiring 
in  several  logical  increments  or  phases,  as  follows: 

a.  Phase  1.  Representatives  of  Resource  Sponsors  prepare 
inputs  (increments)  for  Mission  and  Mission  Support  Sponsors, 
with  representatives  of  Platform  Sponsors  preceding 
representatives  of  other  Resource  Sponsors. 


15  Annex  4,  Part  8,  Department  of  the  Navy  Programming  Manual, 
OPNAV  90P-1D,  5 June  1971,  as  amended. 
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b.  Phase  2 . Mission  and  Mission  Support  Sponsors  aggregate 
the  various  inputs  (increments)  prepared  during  Phase  1 by 
representatives  of  Resource  Sponsors  and  determine  the  viability 
of  the  aggregate.  There  will  probably  be  alternative  increments, 
properly  prioritized,  that  will  allow  several  alternative 
aggregations  to  be  examined. 

c.  Phase  3.  Resource  Sponsors,  in  a manner  similar  to  that 
of  Mission  and  Mission  Support  Sponsors,  aggregate  increments  of 
their  “resources"  prepared  during  Phase  1 by  their 
representatives  and  determine  the  viability  of  the  aggregate. 
Again,  several  different  alternative  aggregations  will'  probably 
be  available  for  examination. 

d.  Phase  4.  The  Manpower  Resources  Coordinating  Panel 
(MRCP)  (or  Op-01  representatives  on  behalf  of  the  MRCP)  aggregate 
*all-Navy“  requirements  by  collecting  the  sponsors'  increments 
and  determine  the  feasibility  of  the  "all-Navy"  aggregation. 
Again,  multiple  alternative  aggregations  will  be  possible. 

The  fact  that  only  four  discrete  phases  are  defined  should 
not  be  interpreted  to  mean  that  only  these  four  phases  will  be 
followed,  or  that  each  phase  will  occur  only  once.  On  the 
contrary,  there  will  probably  be  many  iterations  of  each  phase, 
with  Phase  1 having  the  greatest  number  of  iterations  and  Phase  4 
the  fewest.  Nor  should  the  implication  be  drawn  that  all  four 
phases  must  transpire  in  the  given  sequence.  Indeed,  it  is  quite 
feasible  to  have  some  Phase  3 iterations  preceding  Phase  2 
iterations,  and  it  is  very  likely  that  during  Phase  2 or  Phase  3 
processing  it  will  be  found  necessary  to  perform  more  Phase  1 
iterations  to  correct  significant  disparities. 

In  the  following  paragraphs  the  expected  "scenario"  for  each 
phase  or  increment  is  examined  in  some  detail. 

2,2*2.!  Phase  1 Processing  for  Platform  Sponsors.  To  exemplify 
Phase  1 of  the  NAMPS  "operating  scenario"  as  it  would  apply  to 
Platform  Sponsors,  assume  that  Mr.  John  Smith,  employed  in  the 
mythical  office  of  Op-399,  has  been  tasked  with  the 
responsibility  of  developing  three  alternative  proposals  for 
providing  surface  ship  resources  to  support  surface-to-air 
warfare  under  the  Sea  Control  mission.  He  has  been  given  some 
general  guidance  with  respect  to  alternative  force  structures;  he 
also  has  some  idea  of  the  budgetary  constraints  on  the  MPN  costs 
that  he  will  have  to  try  to  satisfy.  To  develop  his  proposals 
and  determine  their  manpower  requirements  and  costs,  he  will 
exercise  NAMPS  Phase  1 processing  substantially  as  follows: 
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a.  Step* 1 , • Preparation.  Before  attempting  to  develop  his 
proposals  in  automated  form,  Mr.  Smith  does  some  "prior 
planning" : 

(1)  First,  he  reviews  his  copy  of  the  NAMPS  Users 
Manual  promulgated  by  the  NAMPS  System  Services 
Office1^  to  refresh  his  memory  of  how  he  can  use 
NAMPS  AOP  support  to  help  him  develop  his 
proposals. 

(2)  Next,  he  formulates,  in  the  "language"  provided  for 
conversational  interactive  processing  under  NAMPS 
(described  in  the  NAMPS  User  Manual),  the  queries, 
statements,  commands,  etc,  he  will  want  to  use  in 
framing  and  developing  his  proposals. 

(3)  Next,  he  telephones  the  nearest  NAMPS  Terminal 
Facility17  for  an  appointment  to  use  a terminal 
device . 

(4)  Finally,  he  double-checks  his  NAMPS  "credentials" 
stored  in  his  safe  to  insure  he  will  gain  access  to 
that  portion  of  NAMPS  data  he  is  allowed  to  see  and 
use  .18 

b.  Step- 2; ■ Exception.  At  the  NAMPS  Terminal  Facility,  Mr. 
Smith's  identity  is  confirmed  and  he  is  given  access  to  a remote 
terminal  device.  The  sequence  of  steps  that  transpire  at  the 
terminal  is  substantially  as  follows: 

(1)  From  his  prepared  notes,  Mr.  Smith  “signs  on"  at 
the  terminal  and  invokes  the  NAMPS  ADP  Executive 
System  by  a simple  command.  Conversationally,  the 
NAMPS  processor  asks  for  a "countersign"  to 


16  The  NAMPS  System  Services  office  is  conceived  to  be  an 

organizational  element  in  Op-01  responsible  tor  developing 
NAMPS  management  procedures  and  overseeing  the  maintenance 
and  use  of  NAMPS  ADP  support. 

1?  At  least  two  such  facilities  (one  in  the  Pentagon,  one  in  the 
Navy  Annex)  would  be  established  with  two  or  more  terminal 
devices.  Trained  personnel  of  the  NAMPS  System  Services 
Office  would  be  available  to  provide  any  help  needed. 

18  "Credentials"  would  consist  of  "password  and  countersign" 
known  only  to  the  holder,  the  Security  Officer  of  the  NAMPS 
System  Services  Office,  and  the  NAMPS  ADP  system  itself. 
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double-check  Mr.  Smith's  credentials  (a  "password" 
is  included  as  part  of  the  "sign  on"  procedure).19 

(2)  Having  confirmed  Mr.  Smith's  credentials,  the  NAMPS 
processor  then  solicits  Mr.  Smith's  desires.  In 
conversational  English,  guided  by  tutorial  comments 
given  by  the  NAMPS  processor,  Mr.  Smith  asks  for  a 
summary  array  of  manpower  requirements  and  costs 
for  the  current  "base  case", 20  which  is  quickly 
provided,  with  the  option  to  receive  "hard  copy" 
(printed  listing  produced  either  at  the  terminal  or 
at  the  computer  site  for  later  delivery  to  Mr. 
Smith) . 

(3)  Mr.  Smith  is  then  afforded  the  opportunity  to  test 
out  his  first  proposal.  Guided  by  the  processor, 
Mr.  Smith  first  examines  and  then  alters  the 
Required  Operational  Capabilities  (ROCs)  and 
Projected  Operational  Environment  (POE)  for  a 
number  of  ships.  He  might  also  "strike"  some  ships 
and/or  speed  up  commissioning  and  activation  of 
ships  under  construction.  In  tne  latter  case,  if 
ROCs  and  POEs  are  not  available  with  which  to 
project  manpower  requirements,  the  NAMPS  processor 
may  ask  for  help  from  Mr.  Smith  in  setting  up 
manpower  requirements. 

(4)  Having  made  all  his  initial  modifications  to  ROCs 
and  POEs,  Mr.  Smith  then  asks  the  NAMPS  processor 
for  summary  manpower  requirements  and  costs  for  his 
first  "test  case".  He  is  given  an  opportunity  to 
examine  these  results  in  various  levels  of  detail 
(e.g.,  by  Program  Element;  by  class  of  ship;  by 
individual  ship,  if  necessary) . He  is  also  asked 
by  the  NAMPS  processor  if  he  wishes  to  retain  the 
"test  case" . 

(5)  Mr.  Smith  is  not  quite  satisfied  and  asks  to  make 
more  modifications,  which  he  is  allowed  to  do. 


19  These  security  procedures  insure  access  only  by  authorized 
personnel  and  protect  the  privacy  of  data  by  restricting 
authorized  access  to  previously  defined  segments  of  data 
tiles. 

20  A set  of  data  files  prepared  by  the  NAMPS  System  Services 
Office  from  various  "master"  files  as  of  a given  date. 
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Having  readjusted  the  ROCs  and  POEs  to  his 
satisfaction,  Mr.  Smith  decides  to  retain  his  "test 
case-  as  his  first  alternative.  The  processor  asks 
for  a file  identifier  and  a priority  number  and 
then  stores  the  "test  case"  for  future  use, 
creating  appropriate  references  to  it.  The 
statements  of  ROCs  and  POEs  in  the  proposal  are 
then  used  by  the  processor  to  determine  what  the 
support  requirements  for  the  proposal  are  in  terms 
of  underway  replenishment  (ship-to-ship) , resupply 
by  shore  bases,  and  the  concomitant  support  of 
shore  bases  by  other  shore  facilities 
(support-on-support).  The  processor  will  generate 
a second  “support  requirements"  file  containing 
statements  of  operational  and  functional 
capabilities  that  must  be  provided  by  support 
forces  afloat  and  ashore,  creating  appropriate 
references  to  that  file. 

(6)  Mr.  Smith  is  then  given  the  opportunity  to  prepare 
another  “test  case"  if  he  wishes.  Now  Mr.  Smith 
has  a choice:  he  may  go  back  to  the  “base  case" 
data  and  start  again;  or  he  may  make  a copy  of  his 
first  proposal,  modify  the  copy  (without  destroying 
the  original)  , and  thus  create  a slightly  different 
version.  Mr.  Smith  chooses  the  latter  option, 
creates  his  second  proposal,  finds  it  satisfactory, 
and  has  the  NAMPS  processor  store  it  away  with  an 
appropriate  file  identifier  and  priority  number. 

(7)  The  same  process  is  repeated  for  Mr.  Smith's  third 
proposal.  After  he  has  had  his  third  proposal 
stored,  Mr.  Smith  has  some  second  thoughts  about 
priority  numbers.  Again  under  tutorial  guidance  by 
the  NAMPS  processor,  Mr.  Smith  rearranges  his 
priority  numbers  for  his  three  proposals  while  the 
processor  ensures  that  Mr.  Smith  doesn't 
inadvertently  duplicate  his  priorities. 

c.  Stepj 3> 'Evalaation.  Having  finished  his  work  at  the 
NAMPS  Terminal  Facility,  Mr.  Smith  returns  to  his  office  to  await 
any  printed  outputs  he  may  have  ordered.  When  they  are 
delivered,  he  reviews  them,  together  with  printed  results 
received  at  the  terminal.  He  may  find,  after  more  thorough 
review,  that  one  or  more  of  his  proposals  should  be  "updated"  or 
further  modified;  or  he  may  decide  on  a fourth  proposal  that  he 
may  wish  to  substitute  for  one  of  the  others,  or  add  to  his  array 
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of  proposals.  Any  or  all  of  these  alternatives  can  be 
accomplished  during  a second  visit  to  the  NAMPS  Terminal 
Facility. 

2;2;2;2 • Phase*!  - Processing • for>  Other  Resource  Sponsors. 

Basically , the  Phase  1 processing  applicable  to  representatives 
of  other  Resource  Sponsors  is  the  same  as  that  for 
representatives  of  Platform  Sponsors,  with  one  significant 
exception.  As  mentioned  in  the  preceding  paragraph,  when  a 
Platform  Sponsor  representative  saves  a "test  case"  proposal,  the 
NAMPS  processor  not  only  saves  the  data  but  also  automa ticallys 
generates  a file  of  “support  requirements",  with  appropriate 
references.  Now  when  a representative  of  a Resource  Sponsor  who 
is  not  a Platform  Sponsor  “signs  on"  and  is  recognized  by  the 
NAMPS  processor,  the  processor  will  automatically  seek  out  any 
applicable  generated  support  requirements  and  present  them  to  the 
sponsor  representative  for  consideration. 

The  first  requirement  that  the  sponsor  representative  should 
be  prepared  to  cope  with  is  a comparison  of  a summary  of 
generated  support  requirements,  both  those  already  attributable 
to  a specific  activity  and  those  that  are  "unassigned",  to  the 
arrays  of  Required  Functional  Capabilities  (RFCs)  already 
established  in  the  “base  case".  Another  requirement  will  be  to 
provide  the  NAMPS  processor  with  appropriate  annotations 
indicating  what  action  was  taken  with  respect  to  generated 
requirements;  these  comments  will  be  filed  with  the  file  of 
generated  support  requirements. 

Of  course,  the  sponsor  representative  will  probably  wish  to 
alter  RFCs  for  various  shore  activities,  formulating  and  storing 
his  own  proposals  for  supporting  Mission  Sponsors.  For  those 
activities  which  have  no  ROCs,  POEs,  or  RFCs,  sponsors  will  have 
to  work  directly  with  arrays  of  manpower  requirements  data  which, 
for  shore  activities,  can  also  include  civilian  manpower 
requirements  as  well  as  military  manpower  requirements, 

2.2;2;3’ ‘Phase- 2* Processing . Under  NAMPS  Phase  2 processing, 
representatives  of  Mission  and  Mission  Support  Sponsors  would  be 
scheduled  for  appointments  at  an  appropriate  NAMPS  Terminal 
Facility  to  examine  the  various  alternative  proposals  prepared  by 
the  Resource  Sponsors'  representatives.  Subject  to  the  same 
password  and  countersign  procedures,  a Mission  or  Mission  Support 
Sponsor  would  be  allowed  access  only  to  that  data  pertinent  to 
his  area  of  interest.  The  NAMPS  processor  would  first  itemize 
the  proposals  that  have  been  made,  identifying  the  priority 
assigned  to  each.  Then  the  sponsor's  agent  would  be  asked  to 
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identify  those  proposals  he  would  like  to  evaluate  first.  The 
processor  would  provide  a summary  aggregation  of  resources, 
manpower  requirements,  and  costs,  with  "hard  copy"  (printed 
listings)  optional.  The  agent  would  then  be  allowed  to  make  a 
more  detailed  examination  of  the  data,  under  tutorial  guidance 
provided  by  the  processor,  should  he  wish  to  do  so. 

While  agents  of  Mission  and  Mission  Support  Sponsors  would 
not  be  able  to  alter  proposals  prepared  by  representatives  of  the 
Resource  Sponsors,  they  would  be  able  to  create  proposals  of 
their  own  based  on  the  Resource  Sponsors'  proposals,  compare  them 
to  the  Resource  Sponsors'  proposals  and  obtain  printed  listings 
of  the  differences.  They  would  also  be  able  to  prepare  various 
alternative  aggregations  from  different  combinations  of  Resource 
Sponsor  proposals,  for  which  the  NAMPS  processor  would  prepare 
summaries  of  manpower  requirements  ana  costs.  Those  aggregate 
proposals  found  to  be  acceptable  would  be  stored  and  referenced. 

2 1 2 i 2 : 4 • • Phase*  3- Processing . In  most  aspects,  NAMPS  Phase  3 
processing  will  duplicate  Phase  2 processing,  except  that  the 
data  processed  will  be  that  data  pertinent  to  a specific  Resource 
Sponsor.  The  one  significant  difference  will  be  that  Resource 
Sponsor  representatives21  will  be  able  to  modify,  alter,  or 
replace  any  of  the  existing  proposals,  as  well  as  create  new 
ones.  Procedures  will  be  included  in  the  NAMPS  processor  for 
automatically  notifying  Mission  Support  Sponsors  when  changes 
made  by  a Resource  Sponsor  representative  create  new  or  different 
support  requirements. 

liliiib- ‘Phase* 4 - Processing . Before  NAMPS  Phase  4 processing  can 
begin , the  NAMPS  System  Services  Office  must  be  advised  of  the 
number  of  different  aggregations  to  be  evaluated  and  the 
component  parts  of  each  aggregation.  By  the  time  NAMPS  Phase  4 
processing  should  take  place,  so  many  different  individual 
(component)  proposals  can  exist  that  it  would  be  impractical  to 
evaluate  all  possible  combinations.  Therefore,  each  Resource  and 
Mission  (and  Mission  Support)  Sponsor  must  identify  their 
priorities  in  some  form  related  to  their  SPPs  and  further 
identify  the  proposals  that  they  wish  to  have  used. 

With  this  guidance  in  hand,  staff  members  of  the  NAMPS 
System  Services  Office  can  proceed  to  use  the  full  NAMPS  ADP 


21  The  direct  representatives  of  Resource  Sponsors  are  not 
necessarily  the  same  as  those  who  originally  prepared  the 
various  proposals.  They  would  be  authorized  to  address  the 
entire  range  of  resources,  not  just  a segment  of  them. 
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support  to  derive  evaluations  of  the  various  proposals.  After 
"signing  on"  in  the  NAMPS  Terminal  Facility,  a staff  member 
advises  the  NAMPS  processor  of  which  proposals  to  include  in  the 
first  aggregation.  The  NAMPS  processor  will  undoubtedly  have  to 
ask  for  some  specific  assistance  as  it  matches  proposals  to  the 
"base  case"  to  ensure  that  no  existing  activity  is  overlooked. 
When  all  questions  have  been  resolved,  the  processor  can  then 
aggregate  the  manpower  requirements,  cost  them,  and  present  them 
for  preliminary  review. 

In  all  processing  so  far  described,  only  the  capabilities 
provided  by  the  NAMPS  Operational  Requirements  Module,  the  NAMPS 
Manpower  Reference  Model,  and  the  NAMPS  Manpower  Determination 
Model  have  been  exploited.  Assuming  that  an  "all-Navy" 
aggregation  of  sponsors'  proposals  has  so  far  successfully  met 
all  imposed  constraints,  the  next  step  is  for  the  staff  member  to 
direct  the  NAMPS  processor  to  create  a data  file  that  can  be 
further  modified  by  applying  factors  obtained  from  the  NAMPS 
Technology/Productivity  Measurement  and  Facility  Expansion 
Models.  Under  tutorial  guidance  given  by  the  NAMPS  Processor, 
the  staff  member  at  the  terminal  would  review  the  factors  as  they 
are  retrieved  by  the  processor,  determine  their  applicability, 
and  provide  instructions  to  the  processor  with  respect  to  their 
use . 


With  all  appropriate  modifications  completed,  the  NAMPS 
processor  would  automatically  save  the  modified  data  file  and 
then  create  from  it  three  separate  files,  one  for  officer 
manpower  requirements,  one  for  enlisted  manpower  requirements, 
and  one  for  civilian  manpower  requirements.  Each  of  these  three 
files  would  be  used  as  input  by  appropriate  programs  of  the  NAMPS 
Personnel  Inventory  Analysis  Model.  Assuming  that  these  programs 
are  available  for  interactive  processing,  the  results  of  their 
various  processes  would  be  furnished  in  summary  form  to  the  staff 
member  at  the  terminal,  with  more  detailed  “hard  copy"  to  follow 
later  on. 

After  all  alternatives  have  been  considered,  the  NAMPS 
System  Services  Office  will  have  in  hand  computer-generated 
evaluations  of  each  proposed  "five-year  Navy"  showing  manpower 
requirements  (officer,  enlisted,  civilian)  qualitatively  defined 
(designator/grade,  rate/rating,  grade/series),  together  with 
estimated  costs  and  an  assessment  of  the  ability  of  the  personnel 
inventory  to  satisfy  the  requirements.  These  evaluations  can  be 
discussed  and  weighed  by  the  CNO  Executive  Board  (CEB)  in  their 
final  deliberations  of  the  POM. 
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i) 3' «Pf e*POM  and  * Post^POH*  Processing . While  the  emphasis  in  this 
section  has  been  on  the  support  rendered  by  NAMPS  to  the  “POM 
process"  itself,  it  should  be  noted  that  a considerable  usage  of 
NAMPS  ADP  capabilities  will  be  required  both  before  the  “POM 
process"  begins  and  after  it  is  completed.  Already  mentioned  is 
the  need  for  the  NAMPS  System  Services  Office  to  build  a "base 
case"?  and  when  the  final  POM  has  been  determined,  the  manpower 
requirements  data  which  supports  it  must  be  translated  into 
authorizations  and  data  base  updates  for  those  applications  and 
offices  that  help  prepare  the  budget.  Finally,  it  must  be 
mentioned  that  maintenance  of  the  basic  data  files  needed  to 
support  the  NAMPS  processing  described  in  this  section  will  be  a 
basic  continuing  requirement;  this  aspect  will  be  discussed  in 
more  detail  in  a later  section  of  this  report. 
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SECTION  3.  RECENT  DEVELOPMENTS 

The  1974  NAVCOSSACT  report22  identified  a number  of  planned 
and  on-going  ADP  applications,  some  of  which  were  initial  efforts 
to  provide  support  for  NAMPS  and  some  of  which  were  considered 
"interim  support"  for  manpower  planning  pending  development  of 
NAMPS  itself.  In  addition,  numerous  problems  were  identified  and 
questions  raised  with  respect  to  the  feasibility  for  developing 
ADP  support  for  certain  NAMPS  concepts.  This  section  examines 
some  of  the  efforts  that  have  been  undertaken  and/or  completed 
since  the  previous  report  was  published. 

3t 1 « * Appl ieat ions* Under  »CNQgQM/MIS . Among  the  various  ADP 
applications  identified  in  the  1974  report  were  a number  of 
projects  being  developed,  or  proposed  for  development,  by 
NAVCOSSACT  under  the  egis  of  CNOCOM/MIS.23  Three  projects  have 
been  completed  and  placed  in  production  (operational)  status;  a 
fourth  project  has  recently  been  started,  while  enhancements  to 
or  modifications  of  existing  applications  have  already  been 
undertaken  or  are  being  contemplated. 

3il tl  • -Activity  Reference -File  { ARF) . The  successful  development 
and  implementation  of  the  Activity  Reference  File  represents  a 
major  step  forward  in  the  development  of  ADP  support  for  NAMPS. 
The  concept  of  the  ARF  as  a key  requirement  for  NAMPS  ADP 
support,  the  range  of  data  that  it  would  contain,  the  procedures 
by  which  the  ARF  data  base  would  be  maintained,  and  the  concepts 
of  how  the  data  base  would  be  used  were  discussed  in  some  detail 
in  the  prior  report. 2^  The  ARF  data  base  has  been  created  and  is 
being  updated  several  times  each  month  with  data  from  the 
Manpower  and  Personnel  Management  Information  System  (MAPMIS) , 
the  Ships  Management  Information  System  (SMIS)  , and  the  Navy  Cost 
Information  System  (NCIS) . As  of  25  March  1976,  over  9000 
separate  Navy  “activities"  were  recorded  in  the  ARF  data  base. 

Of  the  more  than  50,000  records  in  the  master  file,  over  16,000 
records  contain  data  representing  the  current  status  of 
activities;  over  1000  records  contain  data  reflecting  planned 
changes  to  the  status  of  activities;  almost  14,000  records 
contain  historical  information  (status  of  activities  prior  to 
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recent  changes);  over  6000  records  contain  cross-reference 
information  describing  component  and/or  subordinate  activities; 
and  the  balance  of  the  records  contain  "audit  trail"  data 
reflecting  the  currency  of  data  values  for  the  different 
activities. 

In  addition  to  the  ARF  Master  File,  four  peripheral  index 
files  and  an  ARF  "dictionary"  are  automatically  updated  as  part 
of  the  periodic  updating  process.  The  ARF  dictionary  contains 
various  types  of  tables  used  as  part  of  the  data  acquisition, 
maintenance,  and  reporting  processes,  while  the  four  index  files 
maintain  cross-references  showing  where,  in  the  ARF  Master  File, 
different  values  for  certain  key  data  elements  can  be  found.25 
For  example,  every  "activity"  in  the  ARF  Master  File  is  indexed 
in  one  file  under  the  5-character  Unit  Identification  Code  (UIC) 
or  codes  for  that  activity;  all  MAPMIS  10-digit  Activity  Codes 
are  indexed  in  a second  file;  the  distinct  record  keys  that  are 
unique  to  the  records  provided  by  each  of  the  “source  systems" 
(MAPMIS,  SMIS,  NCIS)  are  indexed  in  a third  file;  and  the  fourth 
file  cross-references  all  Program  Element  (PE)  code  values  found 
in  the  ARF  Master  File. 

At  present,  data  retrieval  from  the  ARF  is  limited  to 
fixed-format  exception  reports  and  exception  and  discrepancy 
listings  that  are  by-products  of  the  data  acquisition  and 
maintenance  processes.26  Most  of  these  reports  were  designed  to 
satisfy  specific  informational  needs  within  Op-01;  however,  one 
reporting  capability  could  be  of  use  to  others.  The  "selective 
activity  display"  format  provides,  for  any  specified  activity  and 
for  one  of  three  time  frames,  the  array  of  data  in  the  ARF  Master 
File.  The  time  frames  that  can  be  specified  are  current  data 
only  (Report  Format  1) , current  data  plus  projected  (future) 
changes  (Report  Format  2),  and  past,  present  and  future  data 
(Report  Format  3).  Provided  the  same  time  frame  is  used,  any 
number  of  activities  identified  by  a 10-digit  activity  code  or 
one  of  the  "source  system"  keys  can  be  printed  out. 

The  ARF  is  also  used  by  the  Qualitative  Requirements 
Application  (QRA)  as  a source  of  information  relevant  to  its 
processing.  The  information  is  retrieved  selectively, 
dynamically,  and  immediately  by  interaction  through  specially 
designed  "linkage  modules".27  While  these  "linkage  modules"  have 
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been  specifically  "tailored**  for  the  QRA , they  can  readily  be 
modified,  adapted,  or  enhanced  to  satisfy  requirements  of  other 
applications.  This,  in  fact,  is  being  done  to  satisfy  the  needs 
of  the  Qualitative  Requirements  Application  for  Officers  (QRAO) . 

3.1;2  Shore  Required  Operational  Capabilities  (SHOROC).  Another 
data  base  of  considerable  significance  to  NAMPS  is  that  being 
developed  and  maintained  by  the  SHOROC  system.  This  system  was 
also  described  in  some  detail  in  the  1974  NAVCOSSACT  report. 28 
Operational  since  December  1974,  the  amount  of  data  in  the  data 
base  has  been  increasing  over  the  past  year  or  so  to  the  point 
that  as  of  mid-March  1976  input  from  322  shore  activities  has 
been  accepted  for  a total  of  over  51,000  statements  of  Required 
Functional  Capabilities  (RFCs). 

There  are  several  sources  of  input  for  the  SHOROC  data  base. 29 
Most  of  the  inputs  are  cards  punched  from  coding  sheets  prepared 
by  the  various  shore  activities  or  by  the  system  user,  the 
Manpower  Requirements  Branch  (Op-124);  however,  two  automated 
systems  also  provide  data  used  by  the  SHOROC  system.  Activity 
information  is  obtained  from  a magnetic  tape  file  furnished  by 
the  Unit  Identification  Application  (UIA)  , maintained  on  the 
Honeywell  6000  computer  at  NAVCOSSACT,  while  information 
concerning  relationships  between  Unit  Identification  Codes  (UICs) 
and  Program  Element  (PE)  codes  is  provided  by  Dictionary  90  of 
the  Navy  Cost  Information  System  (NCIS) , maintained  on  the 
NAVCOSSACT  UNIVAC  equipment. 

In  addition  Fo  the  information  about  shore  activities  and 
the  RFCs  for  each,  the  SHOROC  system  has  an  index  file  that 
allows  identification  of  all  activities  having  given  RFCs.  The 
index  file  is  updated  concurrently  with  the  updating  of  the 
master  file;  it  is  used  during  the  generation  of  certain  reports. 
The  SHOROC  system  also  maintains  the  SHOROC  dictionary  that 
defines  the  various  codes  to  be  used  by  shore  activities  when 
submitting  their  SHOROC  inputs  (RFC  statements  and  modifiers, 


28  NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974, 
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mission  areas,  scope  statements,  limiting  parameters)  ;30  it  is 
reissued  periodically  by  Op-124. 

Currently,  all  SHOROC  processing  is  done  in  “batch"  mode. 
While  the  SHOROC  Reports  Subsystem  can  produce  some  eight 
different  report  formats  varying  from  an  itemization  of  all  RFCs 
for  a given  activity  to  a summary  listing  of  all  activities 
having  a given  RFC,  no  interactive  query  capability  exists. 

There  is  also  no  current  interface  between  SHOROC  and  other 
manpower  planning  applications  under  CNOCOM/MIS;  its  primary 
interface  is  with  the  Navy  Manpower  Requirements  System  (NMRS) 
being  developed  by  the  Navy  Manpower  and  Material  Analysis 
Center,  Atlantic  (NAVMMACLANT) , for  which  up  to  three  different 
data  base  tapes  can  be  created  when  requested  by  Op-124  .31 

3.1.3'  Qoal itative  Requirements 'Appl ication  (QRA) . Identified  in 
the  1974  report  as  an  application  providing  inter im  support  for 
NAMPS,32  the  QRA  may  actually  have  a permanent  role  in  NAMPS  even 
though  in  itself  it  is  not  "workload-driven".  Its  basic  function 
is  to  match,  activity  by  activity,  the  authorized  end  fiscal  year 
strength  figures,  found  in  the  MAPMIS  Manpower  Requirements  Plan 
(MARP),  to  authorized  billets  founo  in  the  MAPMIS  Enlisted  Billet 
File;  determine  what  differences  must  be  adjusted;  determine,  by 
rate  and  rating,  how  those  differences  should  be  distributed  so 
as  to  best  maintain  desired  rating  levels,  grade  balances  and 
sea/shore  ratios  Navy-wide;  and  finally  allocate,  by  rate  and 
rating,  the  necessary  adjustments  to  bring  unbalanced  activities 
into  balance  with  the  MARP  figures. 33 


Operational  since  October  1975,  the 
demonstrated  that  it  can  rapidly  produce 
Plan  (ERP)  that  is  acceptably  accurate.  , 
three  subsystems:  a Controls  Maintenance 


QRA  has  successfully 
an  Enlisted  Requirements 
The  QRA  consists  of 
Subsystem  for 


3D  Enclosure  (1)  to  OPNAVINST  5310.12,  15  November  1974,  "Shore 
Requirements,  Standards,  and  Manpower  Planning  System 
(SHORSTAMPS) " 
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maintaining  files  of  user-supplied  guidance  with  respect  to  grade 
structure,  rating  floors,  and  sea/shore  ratios;  an  ERP 
Create/Update  Subsystem  that  creates  (or  updates)  an  ERP  data 
base;  and  a Reports  Generation  Subsystem  for  producing  the  ERP 
itself  and  (optionally)  displays  of  ERP  data  at  the  activity 
level.34  The  ERP  Master  File  generated  by  the  ERP  Create/Update 
Subsystem  contains  all  MARP  and  Enlisted  Billet  Summary  Data 
supplied  as  input  to  the  program;  a record  of  how  that  data  was 
modified  because  of  "unmatched  activity"  conditions;  all  "net 
changes"  generated  by  the  program's  algorithm  and  applied  by  rate 
and  rating  at  the  activity  level;  and  the  summary  data  that  was 
derived  for  the  ERP  itself.35 

All  subsystems  provide  printed  outputs  which  reflect  the 
results  of  data  processing.  The  ERP  Create/Update  Subsystem 
produces  10  different  listings,  some  of  which  are  optional  or 
exception  reports.  Five  of  these  listings  are  "audit  trails" 
showing  the  user  just  how  the  program's  algorithm  calculated  the 
changes  that  should  be  made;  one  is  a draft  ERP;  one  reflects  the 
effects  of  the  grade  guidance  that  was  used;  others  show  input 
errors  and  tapes  used;  and  one  optional  listing  provides 
activity-level  data  displays  showing  rate/rating  changes  for 
those  activities  for  which  the  magnitude  of  change  for  the 
activity  equalled  or  exceeded  a user-supplied  value.36  The 
latter  report  format  can  also  be  supplied  by  the  Reports 
Subsystem  for  selected  activities  identified  by  10-digit  Activity 
Codes.37 

The  ARF  system  described  in  paragraph  3.1.1  plays  two  roles 
in  the  QRA  processing.  First,  as  a byproduct  of  the  processing 
of  MAPMIS  input  data  for  the  ARF,  the  computer  program  generates 
a machine-readable  file  that  is  made  available  (on  magnetic  tape) 
as  the  MARP  end-strength  file  used  as  input  to  the  ERP 
Create/Update  Subsystem.  Second,  the  ARF  "linkage  modules" 
incorporated  into  QRA  programs  allow  dynamic  access,  on  an  "as 
required"  basis,  to  the  files  of  the  ARF  data  base.  These 
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to  the  following 


modules  are  capable  ot  providing  answers 
questions : 

a.  There  are  billets  written  in  the  tnlisted  Billet  File 

for  an  activity,  but  there  are  no  matching  end  strengths 
in  the  MARP  file.  Where  are  the  end  strengths  to  be 
found?  * 

b.  Conversely,  there  are  end  strengths  authorized  but  no 
billets  written.  Where  are  the  billets,  if  any,  to  be 
found? 

c.  If  no  billets  have  been  written  as  yet,  what  activities 
of  the  same  type  have  billets  written  that  can  be 
checked  for  use  as  a "prototype“? 


In  addition,  one  set  of  modules  can  provide,  when  needed  for 
activity-level  reports,  items  of  information  about  the  activity, 
such  as  10-digit  Activity  Code,  Activity  Name,  etc.,  that  are  not 
part  of  the  ORA  data  base.38  4 


As  a last-minute  addition  to  the  ORA,  the  capability  was 
developed  to  produce  a punched-card  output  containing  the 
Navy-wide  summary,  by  rate  and  rating,  ot  the  adjusted  billet 
data  that  appears  in  the  printed  FRP.  This  additional  output 
provided  as  a primary  input  for  "POM-78"  processing  by  the 
“Mini-NAMPS"  system  (see  paragraph  3.2.3  below). 


was 


3.1.4  Qualitative  Reqoirements  Application  for  Of t iccrs - (QRAQ> . 
The  QRAO  currently  under  development  is  intended  to  perform,  Eor 
officer  manpower  requirements,  the  same  functions  that  the  QRA 
does  for  enlisted  manpower  requirements  and  in  somewhat  the  same 
way.  The  officer  billet  data  will  be  provided  in  summarized  form 
by  the  MAPMIS;  the  MARP  end-strength  data  for  officers  will  be 
provided  by  the  ARF , currently  being  ennanced  to  meet  that 
requirement.  Problems  of  unmatched  activities  (billets  but  no 
end-strengths  and  vice  versa)  will  be  resolved  through 
interfacing  with  the  ARF  as  in  the  QRA.  The  basic  QRAO  output 
will  be  an  Officer  Requirements  Plan  (ORP)  and  an  ORP  data  base. 


The  QRAO  consists  of  three  subsystems:  a Create  Subsystem, 
which  builds  an  initial  ORP  data  base  from  MARP  and  billet  data; 
a File  Maintenance  Subsytem,  through  which  changes  are  applied  to 
“balance"  billet  data  (by  activity)  to  end-strength  data;  and  a 
Report  Generation  Subsystem  for  generating  the  printed  ORP 
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document  and  other  reports.  The  primary  difference  between  the 
QRA  and  the  QRAO  lies  in  the  methodology  for  “balancing"  the 
master  files,  while  the  QRA  employs  a complex  algorithm  that 
functions  automatically  (with  or  without  user  constraints)  and 
runs  in  the  batch  mode,  the  QRAO  will  use  the  following 
methodology:39 

a.  The  Create  Subsystem  will  generate  an  Activity  Exception 
Report  that  will  identify  those  activities  that  are  not 
ih  balance  with  respect  to  end-strength  vs  billets  and 
provide  a Billet  Summary  Listing. 

b.  Using  this  listing,  the  Officer  and  Enlisted  Plans 
Branch  (Op-104)  will  determine  what  changes  should  be 
made;  then  through  interactive  processing  using  the  File 
Maintenance  Subsystem,  Op-104  will  apply  changes  and 
“balance  the  books". 

3:1'  'The*  "'Mini^NAMPS" 'System.  The  1974  report  mentioned  briefly 
what  at  that  time  was  a proposed  new  approach  for  manpower  and 
personnel  planning  during  the  POM  cycle  for  POM-77  calling  for 
the  establishment  of  a Manpower  Resources  Coordinating  Panel 
(MRCP) , the  identification  (by  sponsors)  of  both  quantitative  and 
qualitative  manpower  increments  and  decrements  associated  with 
the  POM  development,  and  the  use  of  ADP  support  provided  by 
BuPers  and  B-K  Dynamics,  Inc.,  to  assist  in  assessing  the  effects 
of  changes  in  manpower  requirements.40  The  ADP  system  has 
subsequently  become  known  as  "Mini-NAMPS" . 

3:2;1* -8ystem‘Strnctare' for •PQM*7?.  The  “Mini-NAMPS“  was 
developed  for  POM-77  by  B-K  Dynamics,  Inc.,  Rockville,  Maryland, 
under  joint  sponsorship  of  the  Office  of  Naval  Research  (ONR) ; 
DCNO,  Manpower  (Op-0l);  the  Assistant  Chief  of  Naval  Personnel 
for  Personnel  Planning  and  Programming  (Pers-2) ; and  the  Naval 
Personnel  Research  and  Development  Center  (NPRDC) , San  Diego, 
California.  The  system  was  designed  to  perform  four  major  tasks, 
not  including  a number  of  utility  and  maintenance  tasks.  The 
four  tasks  were  the  formatting,  updating,  and  adjusting  of 
(enlisted)  manpower  requirements;  the  formatting  of  (enlisted) 


39  NAVCOSSACT  Document  No.  53D306,  FD-01,  June  1976, 
“Qualitative  Requirements  Application  for  Officers  (QRAO) 
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personnel  inventory  data  and  interfacing  with  BuPers 
systems/programs;  the  generation  of  reports  relating  to 
(enlisted)  manpower  requirements,  summaries  of  increments  and/or 
decrements  of  manpower  requirements,  and  comparisons  of  manpower 
requirements  with  projected  personnel  availability;  and  the 
generation  of  manpower  cost  reports.  The  "Mini-NAMPS" 
resides  currently  on  the  complex  of  IBM  360/370  computers  at  the 
National  Institutes  of  Health  (NIH)  and  operates  under 
conventions  and  constraints  of  that  site.41 

The  basic  interactions  of  the  “Mini-NAMPS"  are  shown  in 
Figure  3-01;  the  functions  performed  by  each  of  the  four  major 
subsystems  are  shown  in  Figure  3-02.42  Processing  of  data 
basically  was  as  follows: 

a.  Enlisted  manpower  requirements  extracted  by  Op-01  from 

the  MAPMIS  Enlisted  Billet  File  were  processed  into  the 
initial  Requirements  Data  File.  4 

b.  Punched  card  changes  prepared  by  Op-01  personnel  Were 
applied  to  bring  the  requirements  into  line  with  Five 
Year  Defense  Program  (FYDP)  end-strengths. 

c.  Grade  guidance  covering  the  top  six  enlisted  pay  grades 
(E4  thru  E9)  was  applied  and  an  all-Navy  Enlisted 
Requirements  Plan  was  created  for  use  by  the  BuPers 
Advanced,  Strength,  and  Training  Planning  Program 
(ADSTAP)  System. 

d.  Results  of  ADSTAP  processing  were  processed  into  an 
Enlisted  Personnel  Inventory  Data  File  and  apportioned 
(on  a "fair  share"  basis)  to  program  sponsors. 

e.  Costing  data  was  processed  into  a Cost  Data  File. 

f.  Various  manpower  requirements  reports  were  produced  for 
the  initial  "base  case"  data. 

g.  As  increments  and  decrements  of  enlisted  manpc  or 
requirements  were  received,  they  were  entered  tas  card 
input)  and  stored  in  Increment/Decrement  Files. 


41  B-K  Dynamics,  Inc.  report  1R-3-196,  1 July  1975,  "Mini-NAMPS 
Programmer's  Manual",  pp  1-4 

42  B-K  Dynamics,  Inc.  report  TR-3-194,  1 July  1975,  "New 
Developments  in  Navy  Manpower/Personnel  Planning  - Support  of 
tne  POM-77  MRCP" , pp  6-7 
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FIGURE  3-01.  Basic  "Mini-NAMPS"  Interactions 


h.  By  selective,  temporary  application  of  increments  and/or 
decrements  to  “base  case"  files,  various  alternative 
manpower  requirements  data  sets  were  created,  matched  to 
inventory  data,  costed,  and  evaluated. 

i.  After  all  POM-77  decisions  were  made  and  appropriate 
data  changes  applied,  a final  set  of  all-Navy  enlisted 
requirements  was  prepared  for  the  BuPers  ADSTAP  system. 

3a 2 : i- ' System • Re sol ts . As  with  any  new  system,  problems  were 
encountered . Large  amounts  of  manually  prepared  card  input 
called  for  hundreds  of  man-hours  of  preparation  effort;43 
management  outputs  were  designed  on  a case  by  case  basis,  during 
the  POM  process,  because  users  of  the  system  were  unable  to 
define  their  needs  explicitly  until  experience  was  gained. 44 
Nevertheless,  the  system  did  succeed  in  providing  significant 
data  that  allowed  a manpower  assessment  to  be  completed  for 
POM-77  six  months  earlier,  and  in  greater  detail,  than  for  any 
previous  POM  cycle.45  Manpower  costs  were  assessed  with'  greater 
accuracy  than  before,  and  training  needs  became  known  almost  a 
year  earlier  than  was  previously  possible.46 

3:2; 3* • System 'Changes • for • POM* 78.  To  enhance  and  improve  the 
capabilities  of  the  p6m-77  “Mini-NAMPS"  for  POM-78,  B-K  Dynamics, 
Inc.,  proposed  the  following:47 

a.  Inclusion  of  a tracking  system  for  requirements  by  Navy 
Enlisted  Classification  (NEC)  codes  so  that  a "C"  School 
Training  Plan  can  be  projected. 

b.  Inclusion  of  inputs,  processing,  and  outputs  for  officer 
requirements. 


43  Ibid,  p 47 

44  Ibid,  p 45 

45  Ibid,  p 2 

46  Ibid,  p 28 

47  B-K  Dynamics,  Inc.,  Proposal  BKD-2374, 
"Proposal  to  Implement  POM-78  NAMPS" 


1 December  1975, 
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c.  Refinement  of  algorithms  for  projecting  support 
overhead.  Quantitative  data  reflecting  force/support 
estimates  will  be  obtained  from  the  Navy  Resource  Model 
(NARM)  and  the  support  quantities  "qualitized"  by 
"Mini-NAMPS"  software. 

d.  Inclusion  of  methodology  tor  "quantizing"  billet 
changes  applied  "across  the  board"  (e.g.,  10% 
reduction) . 

e.  Inclusion  of  capability  for  dynamic  inventory 
projection,  reducing  the  frequency  of  interfacing  with 
the  ADSTAP  system. 

f.  Expansion  of  interactive  processing  capabilities. 

g.  Expanded  interfaces  with  other  systems  (Figure  3-03).  » 

The  systems  to  be  used  include: 

(1)  MAPMIS,  the  host  system  for  the  "RENLQUAL"  and 

“ ROFFQUAL"  data  files.  The  " ROFFQUAL"  file  will  be 
the  source  of  officer  billet  data;  the  “RENLQUAL" 
is  the  source  of  enlisted  billet  requirements  by 
NEC. 

(2)  ADSTAP,  the  BuPers  system  for  modellin.  personnel 
inventory  plans  and  requirements.  48 

(3)  ”C“  School  Training  Model;  develops  the  “C“  School 

Training  Plan.  , 

(4)  Modified  Force  Analysis  and  Simulation  Technique 
(M-FAST)  model.  This  is  an  interactive  processor 
developed  under  ONR  sponsorship  that  approximates 
the  outputs  of  a batch-oriented  model  in  ADSTAP  and 
develops  personnel  inventory  projections 
dynamically. 


48  For  details,  see  NAVCOSSACT  Document  no.  53D109,  TR-01 , 
September  1974,  "CNOCOM/MIS  Support  for  the  Navy  Manpower 
Planning  System  (NAMPS)",  p 55  etseq 
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(5)  NAHM;  source  of  factors  for  deriving  quantitative 
estimates  of  manpower  required  for  support 
functions  needed  tor  the  operating  and  support 
forces . 

(6)  QKA  (see  paragraph  3.1.3);  source  of  enlisted 
manpower  requirements,  by  rate  and  rating,  balanced 
to  January  FYDP  end  strengths. 

To  improve  the  quality  of  input  data  for  manpower,  increments 
and  decrements,  a new  and  comprehensive  data  collection  document 
has  also  been  developed.45  The  form  contains  sufficient 
information  to  permit  a computer-generated  itemization  of 
approved  billet  changes  that  can  be  applied  almost  immediately  to 
the  MAPMIS  billet  files. 

3.3' -Navy  Manpower • Requirements  System ■ (NMRS) . In  the  1974 
report  the  NMRS  being  developed  by  the  Navy  Manpower  and  Material 
Analysis  Center,  Atlantic  (NAVMMACLANT)  was  cited  as  the 
foundation  for  the  NAMPS  Manpower  Reference  Model  (MRM)  and  was 
described  in  some  detail,  based  on  information  set  forth  in  the 
System  Requirements  Plan  for  the  NMRS.50  More  recent  information51 
indicates  that  a number  of  system  design  changes  have  been  made, 
a data  base  management  system  is  to  be  used  for  storage  and 
retrieval  of  system  data,  and  new  requirements  have  been  levied. 

3;3.1  Current  NMRS'System  Design.  The  NMRS  consists  of  seven 
major  interfacing  subsystems,  each  having  its  own  unique 
functions  (Figure  3-J4).  The  ultimate  products  of  the  NMRS  are 
the  manpower  documents  presenting  the  minimum  quantitative  and 
qualitative  manpower  requirements  for  given  activi ties ,5^  The 
processing  sequence  through  the  seven  subsystems  is  as  follows:53 


49  B-K  Dynamics,  Inc.,  undated  manual  "Manpower  - Data 
Collection  Sheets  tor  POM-78" 

50  NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974, 
“CNOCOM/MIS  Support  tor  the  Navy  Manpower  Planning  System 
(NAMPS)",  p 20  et  sea 

51  NAVMMACLANT  Briefing  Document,  9 January  1976,  "Navy  Manpower 
Requirements  System  (NMRS)" 

52  Ibid,  NMRS  Overview  Section,  p 3 

53  Ibid,  NMRS  Overview  Section,  p 3 e t seq 
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INPUT 


FIGURE  3-04.  The  NMRS  and  its  Subsystems 


» 


a.  Control  Subsystem.  The  Control  Subsystem  processes  all 
input  data  transactions,  selectively  validating  certain  fields, 
placing  valid  transactions  in  a common  work  file,  and  rejecting 
transactions  that  cannot  be  validated.  After  all  input  data  has 
been  processed,  the  work  file  is  then  sorted  to  a predetermined 
sequence  and  read.  Based  on  control  data  in  the  work  tile 
records  the  Control  Subsystem  "calls"  another  subsystem  to 
further  process  a set  of  transactions.  The  subsystem  monitors 
processing  by  other  subsystems,  evaluates  results,  and  maintains 
the  status  of  the  processing. 

b.  Mission KOC , POE , (MRP)  Subsystem.  The  MRP  Subsystem 
processes  input  transactions  into  appropriate  NMRS  data  base 
files  for  organizational  activities.  Required  Operational 
Capabilities  (ROCs) , Projected  Operational  Environment  (POE), 
Required  functional  Capabilities  (RFCs)  and  other  tasking 
statements.  Input  data  comes  from  two  sources,  the  work  file 
created  by  the  Control  Subsystem  and  a magnetic  tape  file 
provided  by  SHOROC  (see  paragraph  3.1.2  above). 

c.  Skills  and  Constraints  Sabsystem.  The  Skills  and 
Constraints  Subsystem  processes  input  transactions  in  the  work 
file  into  NMRS  data  base  files  pertaining  to  enlisted  ratings, 
officer  designators,  Navy  Enlisted  Classification  (NEC)  codes. 
Naval  Officer  Billet  Codes  (NOBC) , occupation  codes,  paygrade 
distribution  and  compression,  work  week  compression,  and  billet 
titles.  Based  on  evaluation  of  the  input  data,  the  subsystem  may 
generate  other  types  of  transactions  for  the  NMRS  data  base 
(“system-generated  transactions")  . 

d.  Standards  Sabsystem . The  Standards  Subsystem  processes 
input  data  transactions  and  "system-generated  transactions"  into 
those  NMRS  data  base  files  pertaining  to  staffing  standards, 
equations,  tables,  organizational  structures,  directed 
requirements,  and  non-RFC  standards. 

e.  Document  ■ Incut  Processor  (DIP)  Subsystem.  The  DIP 
Subsystem,  based  on  organizational  identification  codes  supplied 
as  input  to  the  work  file,  accumulates  from  the  work  file  and  the 
(updated)  NMRS  data  base  files  the  data  necessary  to  create  work 
load,  watchstation , and  non-billet  RFC  records  used  by  the  next 
subsystem,  storing  the  data  in  the  NMRS  data  base. 

f . Billet  Position -Converter  and  Optimizer • (BILCO) 
Subsystem"  Acting  on  the  data  records  created  by  the  DIP 
Subsystem  and  retrieving  from  the  NMRS  data  base  such  other  data 
it  may  require,  the  BILCO  Subsystem  creates  a set  of 
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billets/positions  in  an  organizational  structure  that  provides 
the  manpower  required  to  satisfy  the  given  work  load.  The 
records  are  then  used  to  update  billet  files  in  the  NRMS  data 
base . 


g.  Output' Generator  (OP'GEN) -Subsystem.  The  OP  GEN 
Subsystem  processes  input  transactions  containing  textual 
information  for  documents  and  listings  into  the  NMRS  data  base 
and  generates  report,  listing,  and  document  parameters  to  be  used 
by  the  commercially  procured  report  generator  program  (“CULPRIT") 
to  produce  the  printed  outputs. 

3s 3 >2*  * NMRS >Dafca  « Base.  The  NMRS  data  base  consists  of  a variety 
o’?  files  grouped  in  to  five  general  categories  (Figure  3-05),^ 
tasking,  skills,  constraints,  billets  ("BILCO"),  and  a reference 
area.  These  files,  or  subsets,  of  the  NMRS  data  base  are  managed 
by  a commercial  data  base  management  system  called  the  Integrated 
Database  Management  System  (IDMS).^^  IDMS  was  selected  by 
NAVMMACLANT  after  review  of  several  commercially  available  data 
base  management  systems  on  the  basis  that  it  best  met  "all  of  the 
NAMPS  data  base  requirements",  that  it  offered  the  maximum 
flexibility  in  data  base  structure,  and  that  it  was  the  only  data 
base  management  system  that  implemented  specifications  for  such 
systems  issued  by  the  Conference  on  Data  Systems  Language 
(CODASYL)  ,56 

3;3;3’  New • Requirements . The  basic  concept  of  the  NMRS  design, 
as  originally  conceived  and  subsequently  modified  as  described  in 
paragraph  3.3.1  above,  centers  around  the  production  of  printed 
documents  containing  manpower  requirements  derived  from  a single 
set  of  required  operational  or  functional  capabilities  for  each 
Navy  activity  for  which  data  has  been  collected.  To  satisfy 
NAMPS  requirements,  there  must  be  capabilities  available  that 
will  cope  with  the  following  conditions: 

a.  Manpower  requirements  data  must  be  provided  within  NAMPS 
for  all  Navy  activities,  including  those  for  which  work 
load  data  has  not  been  collected. 


54  NMRS  figures  have  been  taken  from  the  NMRS  Briefing  Document 
dated  9 January  1976 

55  Ibid,  NMRS  Overview  Section,  pp  7,  8 

56  NAVMMACLANT  ltr  ser  1280/8  of  10  October  1975,  "Data  Base 
Management  System  (DBMS)  Selection",  with  enclosed  report 


39 


NMRS  DATA  BASE  STRUCTURE 
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FIGURE  3-05.  The  NMRS  Data  Base  Components 


b.  For  NAMPS  to  answer  satisfactorily  "what  if"  questions 
dealing  with  variations  of  ROCs,  POEs , and  RFCs,  the 
system  must  provide  a means  of  testing  alternative 
combinations  of  work  load  measurements  and  producing 
equivalent  variations  in  manpower  requirements. 

It  having  been  decided  that  these  capabilities  should  be 
available  for  use  during  “POM-79"  and  that  the  NMRS  should 
provide  them,  these  requirements  (and  others)  were  accordingly 
levied  upon  NAVMMACLANT  with  a firm  completion  (readiness)  date 
of  1 October  1976. 57  To  accomplish  these  tasks,  additional 
resources  were  provided  in  the  form  of  contractor  assistance. 

3i3?4<-  “Mod  if  ieatiows-of  ^ the *€arrew t « NMRS » Be sign . Even  later 
information  reflects  that  NMRS  design  is  still  undergoing 
modification.  The  BILCO  Subsystem  described  above  has  been 
replaced  by  a new  process  called  Billet  Derivation  (BILDER)  ,58 
This  process  consists  of  three  central  subsystems  (Figure  3-06) , 
one  for  ships,  one  for  aviation  squadrons,  and  one  for  shore 
activities.  In  addition  to  replacing  the  BILCO  Subsystem,  the 
new  process  calls  for  some  changes  in  the  DIP  and  OP  GEN 
Subsystems,59  with  which  the  central  subsystems  interface. 


3:4-  ‘Analysis'of'Navy  Military  Manpower ‘Planning.  As  reported  in 
the  19")4  report,  in  mid-1973  research  and  development  (R&D) 
efforts,  whicn  earlier  had  produced  a study  of  existing  computer 
models  for  manpower  and  personnel  management,  were  formally  given 
the  title  "Manpower  Requirements  and  Resources  Control  System" 
(MARRCS).60  In  late  1973,  under  R&D  Advanced  Development  Project 
Number  P43-07X,  the  Navy  Personnel  Research  and  Development 
Center  (NPRDC) , San  Diego,  initiated  “Phase  I"  of  MARRCS,  a 
systems  analysis  and  description  of  current  manpower  planning  and 
decision  processes.61  This  effort  resulted  in  a number  of 


57  CNO  ltr  ser  12/98123  of  23  December  1975,  "Navy  Manpower 
Requirements  System",  with  enclosure 

58  NAVMMACLANT  Functional  Description  dated  15  March  1976,  "NMRS 
Billet  Derivation  and  Associated  Processes". 

59  Ibid,  p 10 

60  NAVCOSSACT  Document  No.  53D109  TR-01,  September  1974, 
“CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS)",  p 15 

61  CNO  ltr  of  30  November  1973,  ser  987E/498,  Subject: 

"Advanced  Development  Project  P43-07X,  'Manpower  Requirements 
and  Resources  Control  System';  implementation  support" 
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Processing 


FIGURE  3-06.  Billet  Derivation  (BILDER)  Process 
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reports  that  described  the  methodology  used  in  conducting  the 
analysis  and  the  results  of  the  analysis  itself. 

One  effort  of  the  MARHCS  Phase  I analysis  resulted  in  an 
overview  of  the  Navy's  participation  in  the  Department  of  Defense 
Planning,  Programming  and  Budgeting  Sytem  (PPBS)  , with  emphasis 
on  the  Navy's  management  structure  as  it  pertains  to  this  system.®2 
Of  particular  significance  are  the  various  tables  and  diagrams 
that  portray  the  interrelationships  of  the  different  types  of 
sponsors,  e.g.,  Mission  Sponsors  and  Force/Function  (Resource) 
Sponsors;  Mission  Sponsors  and  Program  Element  Sponsors,  etc. 

A second  effort  of  the  Phase  I analysis  resulted  in 
schematic  “flow  charts"  of  the  functions  of  major  offices  of  the 
Assistant  Deputy  Chief  of  Naval  Operations  (Manpower  Planning  and 
Programming) (Op-01C)  using  the  Operation  Sequence  Diagram  (OSD) 
techniques.®4  These  diagrams  helped  to  identify  some  "70 
internal  and  external  organizational  interfaces  relating  to 
manpower  planning"  and  a minimum  of  400  functional  interactions 
related  to  manpower  planning  that  are  carried  out  on  a continuing 
basis  ,65 

Concurrently  with  these  efforts,  a data  collection  document 
of  considerable  complexity  was  devised  as  a means  of  gathering 
information  with  which  to  analyze  the  information-processing 
network  involved  in  the  manpower  planning  process.®6  The 
questionnaire  was  aimed  at  identifying,  for  each  “communication" 
between  two  participants  in  a manpower  planning  function,  not 
only  the  nature,  intent  and  content  of  the  "communication"  but 
also  how  each  of  the  two  participants  (the  "producer"  of  the 
“communication"  and  its  recipient)  evaluated  the  worth  of  the 
"communication".  Separate  sections  of  the  questionnaire  asked 
for  identification  of  inputs,  processes,  and  outputs  (information 


62  NPRDC  TR  75-iy,  October  1974,  “Navy  Manpower  Planning  and 
Programming:  basis  tor  Systems  Examination" 

63  Ibid,  pp  46,  47,  A-17  et  seq 


64  NPRDC  Special  Report  75-5,  July  1974,  "Exposition  of 

Significant  Manpower  Planning  Decisions  in  a Major  Navy 
Command  Organization"  * 

65  Ibid,  p 67 

66  NPRDC  TR  75-20,  October  1974,  "An  Approach  and 
Instrumentation  for  Management  System  Analysis" 
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flow)  with  which  the  respondent  was  involved;  descriptions  of 
each;  the  type  or  category  of  information  that  described  each 
input  and  output  (eight  choices  were  offered);  specific 
characteristics  of  each  input  and  output  (frequency,  tone, 
format,  etc);  and  many  other  details  covering  utilization, 
benefits,  value,  related  costs,  etc. 

To  process  the  mass  of  details  provided  by  the  returned  data 
collection  documents,  a set  of  interactive  computer  programs 
known  collectively  as  the  Technique  for  Interactive  Systems 
Analysis  (TISA)  was  developed.67  While  specifically  developed  to 
support  the  MARRCS  effort,  TISA  has  been  adapted  for  use  in  the 
Bureau  of  Naval  Personnel  (BuPers)  to  assess  the  current  and 
future  ADP  needs  of  BuPers  and  to  help  in  evaluating  the  effects 
of  the  then  projected  move  to  New  Orleans.6®  The  TISA  data  base 
for  the  MARRCS  Phase  1 study  was  constructed  from  the  data 
contained  on  returned  data  collection  documents  described  in  the 
preceding  paragraph.  Each  “communication"  described  in  the  data 
collection  documents  has  88  attributes,  any  one  of  which,  or  any 
set,  can  be  used  to  begin  an  analysis  using  TISA.6^  TISA 
includes  the  capability  for  "flow-charting"  processes  using  the 
OSD  technique  previously  described,  for  interactively  modifying 
the  data  under  analysis  so  that  alternatives  can  be  tested, 70  and 
for  measuring  costs  and  benefits  of  systems  or  parts  of  systems. 71 
The  TISA  structure  is  depicted  in  Figure  3-07;  its  role  in  the 
MARRCS  Phase  I study  can  be  seen  in  the  graphic  depiction  of  the 
MARRCS  effort  (Figure  3-08)  . 72 

The  ultimate  product  of  the  study  is  a four-part  report73 
that  is  far  too  comprehensive  and  voluminous  to  treat  properly 


67  NPRDC  TR  75-22,  October  1974,  “Technique  tor  Interactive 
Systems  Analysis  (TISA)" 

68  Ibid,  p 18 

69  Ibid,  p 12 

70  Ibid,  p 6 

71  NPRDC  TR  75-21,  October  1974,  “An  Approach  for  Measuring 
Benefit  and  Cost  in  Management  and  Information  Systems" 

72  Figures  are  taken  from  NPRDC  TR  75-22 

73  Draft  NPRDC  report,  April  1975,  “An  Analysis  of  the  Navy 
Manpower  Planning  and  Programming  System" 
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MARRCS  PHASE  I PRODUCTS 


• IDENTIFICATION  AND  DESCRIPTION  OF  THE  SYSTEM 

• MEASUREMENT  OF  CURRENT  SYSTEM  PERFORMANCE 

• ESTABLISH  t0  BASELINE 

• A METHOO  FOR  MAKING  Ij,  t2 

«„  MEASURES 

• A METHOD  FOR  MODELING  SYSTEM  DESIGN 

• IDENTIFICATION  OF  SYSTEM  DEVELOPMENT  NEEDS 


OTHER  TISA  APPLICATIONS 


• RESEARCH  COMMUNITY 

ORGANIZATIONAL  ANALYSIS 
INFORMATION  PROCESSING 
HUMAN  FACTORS 

• OPERATIONAL  COMMUNITY 

MANAGEMENT  ANALYSIS 

• SYSTEM  DEVELOPERS 

RESOURCE  MANAGEMENT 

• DATA  SYSTEM  DEVELOPERS 

DATA  MANAGEMENT 
HARDWARE  NEQUIREIKNTS 


FIGURE  3-08.  Overview  of  MARRCS  Phase  . I 
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within  the  constraints  of  this  review.  The  highlights  of  each  of 
the  four  parts  appear  to  be  the  following: 

a.  Part- One  ? • Management -System' Analysis.  The  bulk  of  the 
report,  of  course,  deals  with  the  analysis  of  the  data  about  1631 
identifiable  "communications"  (interactions)  from  71  usable 
respondent  questionnaires  .74  There  are  numerous  tables  and 
system  descriptions  that  are  either  airect  or  transformed  outputs 
of  TISA.75  of  particular  interest  are  those  results  dealing  with 
costs  and  benefits.  For  example,  the  total  annual  personnel  cost 
for  manpower  planning  was  estimated  at  $11,833  million  (FY  74 
dollars);  this  figure  does  not  include  ADP  support  costs,  fixed 
costs,  overhead,  etc. 76  "Product’*  costs  ranged  from  nothing  to  a 
maximum  of  $746,983;  however,  the  greatest  number  of  “products" 
cost  less  than  $10,000,  with  the  average  cost  being  approximately 
$36,000  which,  when  shared  among  more  than  one  recipient,  became 
an  average  "shared  cost"  of  about  $20,000.77  with  respect  to 
benefits  realized  from  the  existing  system  and  its  products,  the 
report  indicates  that  only  63%  of  the  potential  usefulness  of 
system  “products"  is  being  realized78  due,  in  large  part 
apparently,  to  the  problems  perceived  with  respect  to  timeliness 
and  accuracy  of  the  data.  As  much  as  31%  of  the  system 
information  is  perceived  to  be  inaccurate  most  of  the  time,  while 
the  timeliness  was  perceived  to  be  unsatisfactory  most  of  the 
time  for  37%  of  the  inf ormation .79  An  analysis  of  various 
comments  supplied  by  respondents  supported  the  TISA  results,  for 
more  than  half  the  comments  called  for  improvements  in  timeliness 
or  accuracy. 80 

PaEt'Two 


■ Manpower -Planning  * Process 


b.  

in  large  part  on  observations  rnaoe  during  meetings, 
and  briefings  that  took  place  during  the  POM-77  cycle  and  on 
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interviews  with  various  participants  in  that  process,81  the 
second  part  of  the  final  report  is  an  assessment  of  the  success 
of  the  MRCP  and  the  "Mini-NAMPS“  (see  paragraph  3.2  above), 
including  an  analysis  of  the  doubts,  problems,  and  other 
“intangible-  human  factors  impacting  on  the  POM-77  process  and 
manpower  planning  in  general.  Despite  the  official  recognition 
of  the  MRCP  in  POM  directives82  and  the  acknowledgement  of  past 
problems  associated  with  manpower  planning,  “there  was 
considerable  doubt  among  the  Navy's  top  manpower  management  that 
its  analyses  would  be  appreciated  and  acted  upon"  by  the  CNO 
Executive  Board  (CEB) ; and  there  was  also  an  opinion  held  by  some 
that  Navy's  top  management  was  more  concerned  with  getting  as 
much  "hardware"  as  possible  than  with  ensuring  that  there  would 
be  enough  people  to  run  the  "hardware",82  that  the  CEB  might  not 
want  to  be  told  that  it  should  not  approve  procurement  of  certain 
“hardware"  because  personnel  needed  for  it  would  not  be  available 
in  time.8**  In  fact,  however,  the  assessments  that  were  made 
possible  with  the  new  procedures  received  "high  compliments"  from 
key  members  of  the  POM  Development  Review  Committee  (PDRC)  and  an 
acknowledgement  by  the  CNO  himself  that  the  work  of  the  MRCP  was 
significant.85  The  new  procedures  appear  to  have  resulted  in 
three  main  gains: 

(1)  It  was  found  that  Mission  Sponsors  were  sensitive 
to  the  "manpower  intensiveness"  of  their  programs 
and  were  able  to  identify  both  the  quantity  and 
quality  of  the  manpower  impacts.88 

(2)  Personnel  planners  gained  valuable  lead  time  in 
developing  personnel  programs  that  would  ensure 
that  personnel  would  be  available  to  meet  projected 
manpower  requirements.  The  Chief  of  Naval 
Education  and  Training  (CNET)  was  given  an  “A" 
School  Training  Plan  almost  a year  earlier  than  was 
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previously  possible,  only  3 days  after  the  FY  76 
plan . 87 

(3)  The  synergism  between  manpower  planning  and 

personnel  planning  demonstrated  that  problems  can 
be  predicted  to  a level  of  detail  in  sufficient 
time  for  management  to  find  solutions  during  POM 
deliberations.  For  example,  of  some  three  dozen 
"sick  ratings"  (those  wherein  less  than  90%  of 
programmed  billets  could  be  filled),  all  but  four 
were  made  "well”  by  FY  77  . 88  In  another  case,  it 
was  possible  to  identify  a training  problem  for  the 
CNO  and  obtain  his  suggestion  to  defer  part  of  one 
program  in  order  to  pay  for  the  training 
requirements  of  another. 89 

c . Pa rt* Three  ; Information  Needs ‘of 'Manpower ♦Planning. 

This  section  reports  on  the  results  of  a sampling  of  opinions 
with  respect  to  five  areas  of  interest  relating  to  future 
capabilities  that  will  be  needed  by  a manpower  management  system. 
One  area  of  interest  dealt  with  the  implications  of  a specific 
directive  from  the  Office  of  the  Secretary  of  Defense  (OSD) ; the 
other  areas  were  concerned  with  types  of  "what  if"  questions  that 
a manpower  management  system  should  be  prepared  to  cope  with  and 
the  pros  and  cons  relating  to  the  existance  and  use  of  a 
management  tool  that  could  answer  such  questions.90  A very  large 
number  of  "what  if"  questions  were  derived  from  records  of 
Congressional  budget  hearings.91  These,  and  others  developed  by 
interview,  dealt  generally  with  the  impacts  of  percentage 
reductions  and  the  relationships  of  support  requirements  to 
operating  forces;  projections  of  manpower  requirements  based  on 
changes  in  force  structure;  the  impact  on  readiness  of  changes  in 
a variety  of  Navy  policies;  the  impact  of  base  closures  or 
consolidations  on  fleet  readiness;  the  impact  of  "tension  levels" 
on  manning  levels;  and  improved  forecasting  of  training 
requirements.92  With  respect  to  factors  affecting  the  usefulness 
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of  a comprehensive  manpower  management  system,  a need  to  "rectify 
the  loss  of  credibility  which  Navy  management  has  suffered  in  the 
past  several  years"  appears  to  support  the  development  of  data 
systems  capable  of  substantiating  and  quantifying  answers  to  OSD 
and  Congressional  questions.98  on  the  other  hand,  too  much 
information  from  such  a system;  a perceived  loss  of  command 
prerogative  and  flexibility  because  of  centralization  of  manpower 
planning;  a high  turnover  rate  of  military  managers;  and  a fear 
that  having  such  a system  might  contribute  further  to  a 
"narrowing  of  ...  command  discretion  vis-a-vis  Congress  and  other 
outsiders"  were  seen  as  mitigating  against  acceptance  and  use  of 
a comprehensive  manpower  management  system.94 

d . Pa  el’  Four  > • A • S tr  nc  tarcfor  Accomplishing  Wo  r K load*  based 
Manpower  ■ Kcqu  it  ements  ‘Planning  with  a Pi  sc  as  si  on  • of  Ref  a tc<? 
Development  - Task's . This  section  identifies  three  broad  areas  in 
which  improvements  should  be  developed:  information  processing, 
organizational  representation,  and  technological  expansion.99  in 
the  first  area,  it  is  proposed  that  the  information  flow 
discussed  in  Part  One  be  examined,  data  inputs  "purified"  and 
"integrated",  and  a Data  Base  Management  System  established.9® 
Organizationally,  more  integrating  mechanisms  such  as  the  MRCP 
are  recommended.97  Most  of  the  section  is  devoted  to  exploring 
the  possible  avenues  of  technological  development,  with  emphasis 
on  the  need  for  variability  in  statements  of  UOCs  and  the 
relationships  of  Operating  Force  needs  to  concomitant  support 
requirements.98  A pilot  study  is  proposed  as  an  approach  to 
determine  feasibility  of  variable  ROCs,99  while  the  use  of 
"input/output"  modelling  is  supported  as  the  best  approach  to  the 
force/support  linkage  problem. 100 
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3t  5 ■ Stodies-of- NAMPS ■ Problem  Areas.  Five  major  “problem  areas" 
were  identified  and  described  in  the  1974  NAVCOSSACT  report. 

As  far  as  can  be  determined,  only  one  of  these  areas  has  received 
extensive  study,  that  being  the  problem  of  defining  variable 
operational  requirements  and  deriving  therefrom  the  necessary 
"support  tail”.  The  two  parts  of  this  problem  (ROC  variability 
and  derivation  of  "support  tail")  have  been  studied  separately, 
but  no  study  has  been  made  as  yet  of  how  to  link  solutions  of  the 
two  parts  of  the  problem,  i.e.,  how  to  vary  the  "support  tail" 
based  on  dynamic  changes  to  ROCs  for  the  operating  and  support 
forces. 

3 1 5 1 1 * ♦ Variability -in' Wo rkfoadRegaire me nts.  Under  the 
0££)-sponsored  Snip  Mobility  and  Operational  Readiness  Evaluation 
(SMORE)  program,  the  Navy  was  directed  in  1975  to  evaluate  the 
effects  on  readiness  of  various  ships  of  arbitrary  manpower 
configurations  based  on  percentage  values.  Dissatisfaction  with 
the  nature  of  the  SMORE  program  led  to  its  redirection  using  the 
superior  Readiness  Assessment  Program  (RAP)  which  was  under 
development  at  the  time.  The  latter  program  is  based  on 
assessing  the  operational  capabilities  which  obtain  from  varying 
the  requirements  (and  related  manpower)  in  one  or  more  of  four 
areas  :102 


a.  Endurance,  i.e.,  period  of  time  for  intensive 
watchstanding . 

b.  Workload,  e.g.,  amount  of  time  devoted  to  maintenance. 

c.  Special  evolutions,  e.g.,  underway  replenishment,  flight 
quarters,  etc. 

d.  Operational  requirements  (reduction  or  elimination) , 

e.g.  eliminating  ASW,  manning  one  gun  instead  of  two, 
etc . 

Using  Ship  Manpower  Document  ( SMD)  data  and  methodology,  the  RAP 
process  applies  rational  logic  to  alter  parameters  in  these  areas 
and  derive  reduced  ROC  levels  that  can  be  related  to  manpower 
reductions  to  obtain  the  percentage  of  reduction.  Various 


101  NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974. 
"CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS)",  p 72 

102  Op-121  "talking  paper"  dated  March  1976,  “Readiness 
Assessment  Program" 
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combinations  of  changes  in  parameters  can  be  tested  to  determine 
the  effects  of  each  combination  on  ship  readiness  and  manpower 
requirements . 

While  the  RAP  process  was  originally  developed  as  a manual 
process,  automation  of  the  process  is  considered  feasible  by 
adaptation  of  a computer  program  developed  by  the  Navy  Manpower 
and  Material  Analysis  Center,  Pacific,  (NAVMMACPAC)  in  February 
1976.  This  program  is  known  as  the  Interactive  Manpower  Analysis 
Program  (IMAP) . 

RAP  and  its  automated  version  IMAP  are  considered  to  be  the 
forerunners  for  the  NAMPS  Alternative  Generator  Model.  Since  the 
essence  of  the  RAP  concept  is  the  variation  of  ROC  parameters 
(including  the  reduction  or  elimination  of  specific  ROCs) , its 
use  as  a solution  to  the  problem  of  ROC  variability  cannot  be 
overlooked . 

3.5.2  Determining  Workload  Reauirements  for  Supporting  the 
"Fleet.  Anoth’ef'_ma]o'r  problem  of"  To"ng~ 'standing  is~tnat  of 
relating  support  requirements  to  changing  demands  of  the 
Operating  Forces.  Two  studies  dating  from  the  early  1970s  were 
cited  in  the  1974  NAVCOSSACT  report;l°3  the  more  recent  study  by 
NPRDC  also  commented  on  the  problem  and  cited  on-going  efforts  by 
NPRDC  to  develop  viable  models  using  the  Leontief  input/output 
approach . 104 

In  one  effort,  an  input/output  model  was  constructed  with 
data  selected  from  the  Logistic  Support  Requirement  (LSR)  system, 
"Statistics  of  Navy  Medicine”  for  fiscal  year  1972,  and 
“Personnel  of  the  Naval  Shore  Establishment”  (NAVSO  P-111)  for 
December  1971.105  These  data  pertained  to  twenty  activities  of 
the  11th  Naval  District  selected  for  their  size  and  availability 
of  input  data.l°6  Output  measures  for  the  various  activities 


103  NAVCOSSACT  Document  No.  53D1U9,  TR-01,  September  1974, 
“CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS)”,  pp  38,  39 

104  Draft  NPRDC  report,  April  1975,  “An  Analysis  of  the  Navy 
Manpower  Planning  and  Programming  System"  , pp  229-231 

105  Draft  NPRDC  document  (undated) , "Manpower  Forcasting  for 
Activities  via  an  Input-Output  Model",  p 7 

106  Ibid,  pp  4,  6 


varied  from  dollars  worth  of  contracts  and  man-hours  or  man-days 
expended  to  hospital  admissions  and  numbers  of  students.  Several 
hypothetical  problems  were  "solved-  with  the  model,  including  a 
disestablishment  of  a major  activity,  a percentage  reduction  of 
the. Operating  Forces,  transfers  of  ships  from  one  home  port  to 
another,  etc. 

While  the  model  generated  answers  for  these  hypothetical 
“what  if"  questions,  the  validity  of  the  data  used  as  input  was 
questioned.  The  quantitative  data  from  the  LSR  was  described  as 
varying  in  consistency;107  the  constraints  on  the  choice  of 
output  measures  were  “unsatisfactory".108  There  would  be  a great 
deal  of  labor  involved  in  collecting  data  for  a linear  model  even 
on  an  annual  basis,108  and  the  report  concludes  that 
"implementation  of  the  model  requires  more  work  on  data  sources, 
fleet  structure  and  the  level  of  detail  in  the  model’1.110 

A second  effort  concentrated  not  on  the  use  of  an 
input/output  model  but  “with  the  way  support  for  the  fleet  is 
accomplished”.111  Using  a variety  of  statistical  techniques, 
data  sources,  assumptions,  and  data  analysis  approaches,  a study 
was  made  of  four  different  types  of  activities:  a Navy  Supply 
Center,  where  the  study  concentrated  on  an  analysis  of  customer 
demands  represented  by  requisitions;  a Navy  Calibration 
Laboratory,  where  the  impact  of  budget  and  manpower  constraints 
was  examined;  a Naval  Air  Station,  where  the  study  concentrated 
on  the  problem  of  many  dissimilar  functions  being  performed  that 
do  not  have  a common  measure  of  output;  and  a Navy  Hospital, 
where  the  problem  of  adequate  workload  measurement  without 
adequate  customer  identification  was  examined.112  A fifth  study 
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of  the  impact  of  a proposal  to  change  the  home  port  of  an 
aircraft  carrier  was  terminated  when  it  appeared  that  there  would 
be  no  appreciable  impact.113 

Although  the  studies  were  admittedly  preliminary,  the 
results  of  the  studies  led  to  the  following  conclusions,  among 
others:11^ 

a.  It  is  possible  to  “model"  the  support  structure,  and  the 
data  needed  for  such  a model  exist.  "However  the  data 
are  scattered  among  individual  activities  and  are  often 
in  a raw  form.  Thus,  collection  and  organization  of  the 
data  are  laborious  and  costly." 

b.  "Navy  activities  are  comparable  by  class  on  an  aggregate 

level Consequently,  individual  differences  are  not 

as  critical  as  local  managers  believe." 

c.  As  customers,  units  of  the  Operating  Forces  levy  less 
than  half  the  workload  demands  for  many  shore 
activities;  the  major  portion  of  the  demands  comes  from 
shore-based  customers.  “Consequently,  any  model  linking 
the  fleet  to  the  shore  must  include  second  order  effects 
of  the  fleet  on  an  activity  via  other  activities." 

d.  While  the  requirements  of  customers  within  a class  of 
customers  were  uniform,  there  are  significant 
differences  between  customer  classes. 

e.  "Workload  relationships  change  over  time.  They  depend 
upon  organizational  structure  and  external  events  which 
alter  the  mix  of  demands  by  customer  classes." 

Research  and  development  ( R&D)  effort  in  the  area  of  fleet 
support  demands  is  to  be  continued  over  the  next  five  fiscal 
years  at  an  estimated  aggregate  cost  of  $2.2  million,  with  the 
principal  cost  of  the  models  to  be  developed  being  in  the 
collection  of  data.11^  Work  will  be  done  by  NPRDC . 
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3 ; 6 • * Research  and  Development  (R&D) . Numerous  R&D  initiatives  in 
addition  to  that  cited  in  the  preceding  paragraph  have  been 
proposed  for  the  next  five-year  period.  These  initiatives 
address  problems  that  can  be  divided  into  the  following  general 
areas: 

a.  Development  of  manpower  requirements  during  the 
programming  cycle;  programmed  for  $625,000  in  fiscal 
year  1977. 

b.  Development  of  manpower  requirements  during  the  planning 
cycle;  programmed  for  $575,000  in  fiscal  year  1977. 

c.  Personnel  inventory  management;  programmed  for  $350,000 
in  fiscal  year  1977. 

d.  Interface  between  manpower  planning  and  personnel 
planning;  programmed  tor  $100,000  in  fiscal  year  1977. 

While  it  is  hoped  that  the  R&D  efforts  will  be  continued 
through  the  ensuing  four  fiscal  years  at  the  same  funding  levels 
programmed  for  fiscal  year  1977,  funding  levels  are  subject  to 
change  not  only  because  of  programming  and  budget  considerations 
but  also  because  of  results  of  the  R&D  efforts  themselves. 

3.6.1  R&D  in  Support  of  Requirements  Programming  • In  addition 
to  the  proposed  study  of  the  "flVe  t-suppor  t"  d"emand  network" 
previously  cited,  at  least  two  other  efforts  have  been  proposed. 
One  proposal  cites  the  existence  of  a range  of  problems 
inhibiting  the  integration  of  military  and  civilian  manpower 
requirements  development  and  suggests  a two-year  study  to 
delineate  the  problems,  identify  solutions,  and  develop 
integrating  methodologies .H6  The  other  identified  proposal 
addresses  the  suggestion  that  application  of  economic  analysis  to 
manpower  resource  allocation  can  help  identify  labor-intensive 
Navy  functions  that  are  not  cost  effective  when  compared  to  other 
resource  allocation  alternatives,  suggesting  a three-year  "case 
study"  to  test  the  theory.1!7 

3q6.2  R&D  Support  of  Long-Range  Manpower  Planning . Two  basic 
problem’s  are  addressed  in  this  area:  trie  need  to  develop  tools  to  • 
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permit  forecasting  of  manpower  requirements  and  personnel 
availability  in  the  period  from  five  to  2fc)  years  into  the  future, 
and  the  need  to  introduce  into  the  R&D  cycle  covering  new  Navy 
systems  (platforms,  weaponry,  etc)  tools  and  techniques  that 
ensure  consideration  of  manpower  cost-benefit  alternatives  from 
the  outset.  In  the  first  instance,  the  proposal  suggests  a 
five-year  project  to  identify  and  measure  factors  affecting 
supply  (of  personnel)  and  demand  (required  billets)  and  develop, 
test,  and  evaluate  statistical  models  that  will  forecast,  with 
reasonable  accuracy,  the  long-range  manpower  demands  and 
personnel  availability  under  various  cond i tions .118  In  the 
second  instance,  the  proposal  suggests  a five-year  project  that 
would  produce  computer-assisted  techniques  (models)  that  could  be 
used  by  system  design  teams  to  evaluate  the  manpower  costs  of 
alternative  design  approaches .119 

3.J^._3  _H&D_  SuPP.2.ft  l°r  Personnel  Inventory  Management.  At  least 

seven" R&D  effor  ts  to  develop  improved  personnel  inventory  . 
management  capaoilities  have  been  proposed  tor  the  five-year 
period  beginning  with  fiscal  year  1977.  These  proposals 
recommend : 

a.  Enhancing  an  existing  model  and  developing  additional 
models  to  improve  planning  for  and  management  of  Navy 
officer  personnel .120 

b.  Improving  selection  procedures  for  Naval  Academy  and 
Navy  Reserve  Officers  Training  Corps  (NROTC)  so  that 
career-motivated  applicants  can  be  iden ti f ied .121 
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c.  Identifying  factors  which  motivate  officers  to  remain  in 
the  Navy,  evaluating  the  impacts  on  officer  retention  of 
various  "detailing"  procedures,  and  developing  improved 
techniques  that  would  enhance  those  factors  which 
motivate  officer  career  continuance  .122 

d.  Enhancing  the  existing  enlisted  personnel  planning 
system  to  improve  reaction  and  response  time  and  develop 
capabilities  not  now  available .123 

e.  Developing  an  interactive  network  of  minicomputers  and 
processors  with  data  base  management  capabilities  to 
provide  improved  recruitment  and  assignment 

capabilities. 3-24 

f.  Studying  attitudinal/motivational  factors  which 
influence  decisions  by  Navy  enlisted  personnel  facing 
reenlistment  with  a view  to  developing  knowledge  that 
can  be  used  to  improve  enlisted  retention  rates.3-25 

g.  Testing  the  feasibility  of  using  data  communications 
networks  and  minicomputers  to  improve  personnel  planning 
for  Navy  shore  installations,  known  as  the  Shore 
Activity  Manpower  Planning  System  (SAMPS)  .3-26  This 
system  relates  to  planning  and  management  of  civilian 
personnel,  with  computer  programming  being  done  by 
NAVCOSSACT  under  project  number  02J012.3-27 


Navy  Decision  Coordinating  Paper,  19  January  1976,  "Officer 
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Acquisition" 

Navy  Decision  Coordinating  Paper  (undated)  , "Selective 
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Office  of  Civilian  Manpower  Management  (OCMM)  letter  serial 
64:JV3,  dated  25  Mar  1976,  suoject  "Project  Request  02J012, 
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3;6;4  R&D  Soppog t ■ for  Inter fac ing  Manpower 'and  Personnel 
Planning  Systems.  A five-year  effort  is  proposed  for  modifying 
an  existing  system  by  developing  additional  knowledge  about 
variables  affecting  the  size  and  configuration  of  manpower 
requirements  and  personnel  inventories  and  applying  that 
knowledge  to  enhanced  computer  models.128  Although  not 
specifically  identified  as  such,  the  existing  system  referred  to 
is  the  “Mini-NAMPS“  described  in  paragraphs  3.2  et  seq. 


128  Navy  Decision  Coordinating  Paper  (undated)  , “Planning 
Interface  for  Manpower  and  Personnel" 
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SECTION  4.  ADP  CAPABILITIES  NEEDED  FOR  NAMPS 

In  this  section  an  analysis  is  made  of  the  NAMPS  structure 
and  "operating  scenario"  with  respect  to  data  bases  required, 
software  needed  to  use  and  manipulate  those  data  bases,  and  the 
data  base  maintenance  capabilities  needed. 

4.1  ADP  Implications  of  the  NAMPS  Scenario.  The  general 
implications  tnat  can  be  derived  from  a review  of  the  NAMPS 
scenario  described  in  Section  2 are  as  follows: 

a.  Most,  if  not  all,  ADP  support  for  the  POM  process  must 
be  conversationally  interactive. 

• 

b.  There  is  a wide  range  of  requirements  for  interactive 
processing,  implying  a need  to  compartmentalize  and 
exercise  processing  control  through  an  executive 
supervisor  program. 

c.  Access  to  the  data  in  automated  data  bases  needs  to  be 
carefully  monitored,  implying  a need  for  access  control 
software . 

d.  The  creation  of  an  apparently  unlimited  number  of 
notional  data  files  (sponsor's  proposals)  that  can  be 
retrieved  in  any  combination  or  sequence  implies  a need 
for  automated  file  directory,  file  indexing,  and  file 
retrieval  capabilities. 

e.  The  need  to  create  "base  case"  files  implies  that  there 
will  be  master  data  files  that  will  be  subject  to 
regular  updates;  that  selected  data  in  these  files  needs 
to  be  "frozen"  as  of  a given  point  in  time;  and  that 
100%  duplication  of  master  data  files  for  “base  case" 
files  is  not  required. 

4.2~  Types-of  ADP  Programs  Needed.  The  computer  programs  needed 
to  support  the  ADP  requirements  of  the  NAMPS  operating  scenario 
would  appear  to  fall  into  five  groups: 

a.  Data  base  maintenance  programs  to  create,  update  and 

audit  basic  master  data  files  that  would  be  the  primary 
sources  of  data  for  the  "base  case"  data  files  generated 
for  sponsors'  use. 
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b.  Basic  data  extract  programs  to  construct,  index,  and 
validate  “base  case"  data  files  created  from  data  taken 
from  basic  master  data  files. 

c.  Interactive  programs  with  which  to  create,  update,  and 
manipulate  “notional"  data  files  belonging  to  various 
sponsors . 

d.  Executive  control  programs  to  monitor  ana  constrain  the 
interactive  processing,  identify  and  index  sponsors' 
data  files,  and  maintain  the  security  and  privacy  of 
those  files. 


e.  System  support  programs  to  perform  various  functions 
common  to  different  subsystems. 

All  programs  must  be  functionally  organized  into  subsystems 
focussed  on  specific  types  of  data  or  on  specific  functional 
requirements. 


4.3  Master  Data  Base  Requirements.  It  would  appear  that  a 
number  of  separate  master  data  bases  will  be  required  in  order  to 
provide  the  data  needed  by  NAMPS.  There  can  be  no  accurate 
determination  of  precisely  how  many  separate  data  bases  should  be 
maintained  under  NAMPS  until  there  has  been  a determination  of 
what  existing  automated  data  bases  can  be  used  as  sources  for 
NAMPS  data.  Master  data  files  needed  for  NAMPS  ADP  subsystems 
would  appear  to  include  the  following: 

a.  Operational  Requirements  Files. 

(1)  Statements  of  ROCs , POEs , and  RFCs  for  ships, 
squadrons,  shore  activities,  and  other  navy 
organizations . 

(2)  Statements  of  relationships  between  operational 
requirements  for  fleet  units  and  the  supporting 
functional  capabilities  that  the  Shore 
Establishment  must  provide. 


(3) 


Information  about  Navy  organizations 
relationships  that  exist  among  them, 
has  sponsorship  responsibilities  and 
supportive  interactions  are. 


and  the 
including 
what  the 


who 


b.  Manpower  Reference  Files. 
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(1)  Statements  of  manpower  requirements  related  to 
statements  of  operational  requirements  (Manpower 
Reference  Model). 

(2)  Statements  of  manpowe.r  requirements  not  related  to 
operational  requirements  but  related  to 
organizational  needs  (such  as  QRA  and  QRAO) . 

(3)  Manpower  cost  data. 

c.  Technological  and  Facilities  Forecast  Files. 

(1)  Statements  of  quantitative  factors  applicable  to 
sets  of  manpower  requirements. 

(2)  Algorithms  for  applying  factors.  * 

d.  Personnel  Inventory  Files. 

e.  Supporting  dictionaries,  indices,  equivalency  tables, 

etc . 

4.4  ADP  Support  to  be  Provided  Under  CNOCOM/MIS.  For  reasons 
set  forth  in  paragrapn ~1 . 4 , it  is  not  possible  at  this  time  to 
define  with  any  exactitude  the  entire  scope  of  ADP  support  that 
will  be  asked  for  under  the  aegis  of  CNOCOM/MIS.  However,  some 
general  guidelines  have  been  proposed  that  include  the 
development  of  ADP  systems  to  create,  update,  audit,  and  use 
basic  master  data  files  for  operational  requirements  and  for 
manpower  requirements  unrelated  to  operational  requirements  (see 
paragraphs  4.2a,  4.3a,  and  4.3b(2)  above).  The  general  nature  of 
the  automated  data  files  for  which  maintenance  systems  would  be 
needed  under  CNOCOM/MIS  can  be  described  as  follows: 

a.  Operational  Requirements  Files.  Conceptually,  these 
data  files  would  contain  the  most  recent  officially  approved 
statements  of  Required  Operational  Capabilities  for  Navy  fleet 
units  and  shore  activities.  For  operational  units,  statements  of 
Projected  Operational  Environment  (POE)  would  also  be  needed. 
Because  of  the  differences  in  how  these  statements  need  to  be 
phrased,  it  is  believed  that  the  following  data  files  are  needed: 

(1)  Ship  Required  Operational  Capabilities  (SHIPROC) , 
to  include  statements  of  POE. 

(2)  Squadron  Required  Operational  Capabilities 
(SQUADROC) , to  include  POE  statements. 
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(3)  Shore  Required  Operational  Capabilities  (SHOROC) . 

(4)  Required  Operational  Capabilities  for  Mobile 

Activities  (KOCMA) , such  as  staffs  afloat,  SEAL 
teams.  Explosive  Ordnance  Units,  Construction 
Battalions,  etc.  * 

b.  Suppor t Relationships  Files.  In  Section  2,  paragraphs 
2. 2. 2.1  and  2. 2 7T.~2 , mention  is  made  of  programmatically 
generated  files  of  support  requirements  based  on  the  sponsor's 
proposal  for  fleet  operational  requirements.  If  this  capability 
is  to  be  at  all  feasible,  there  must  be  data  files  (and 
algorithms  for  their  use)  containing  statements  of  relationships 
between  Required  Operational  Capabilities  (ROCs)  afloat  and  the 
support-type  ROCs  and  shore-based  Required  Functional 
Capabilities  (RFCs)  that  define  the  support  needed  for  fleet 
operating  units.  There  could  be  three  types  of • relationships , 
each  requiring  different  phrasing  and  different  forms  of  data 
files: 

(1)  Ship-to-ship  support  relationships,  e.g.,  the  need 
for  underway  replenishment  generated  by  the  ROCs 
and  POEs  for  ships  and  units  afloat. 

(2)  Ship-to-shore  support  relationships,  e.g.,  the  need 
for  shore  supply  facilities  to  support  ships 

and  units  afloat. 

(3)  Shore-to-shore  relationships,  e.g.,  the  need  for 
procurement  functions  to  support  the  shore  supply 
facilities . 

c.  Activity  Status  Files.  The  Activity  Reference  File 
(ARF)  described  m paragraph  3.1.1  would  probably  satisfy  the 
requirements  for  activity  status  data  provided  that  the  system 
capabilities  are  sufficiently  enhanced  to  provide  the  data 
needed.  The  enhancements  that  are  needed  include,  but  are  not 
necessarily  restricted  to,  the  following: 

(1)  Inclusion  of  data  from  aviation  planning  files. 

(2)  Inclusion  of  data  from  civilian  planning  files 
maintained  by  the  Office  of  Civilian  Manpower 
Management  (OCMM) , limited  to  activity 
identification  data  of  the  type  currently  included 
in  the  ARF. 


(3)  Inclusion  of  data  which  reflects  the  satelliting  of 
activities  afloat  and  ashore  on  shore  installations 
for  logistic  support. 

d.  Corrcnt  Manpower  Anthor ization  Files.  The  need  for  data 
files  that  contain  summaries  of  manpower  authorizations  and 
manning  documents  is  justified  by  the  following  considerations: 

(1)  It  has  already  been  conceded  that  there  will  be 
some  Navy  activities  whose  functions  cannot  be 
quantified  or  measured  by  statements  of  ROCs  or 
RFCs;  yet  the  manpower  required  to  run  these 
activities  must  be  considered  when  evaluating 
sponsors'  proposals  in  an  "all-Navy"  environment. 

(2)  As  part  of  the  assessment  of  manpower  impacts,  it 
may  be  desirable  to  display  a •'before'*  and  "after" 
comparison . 

(3)  If  an  approved  Navy  manpower  "suit"  derived  from 
NAMPS  processing  is  to  be  applied  to  existing 
manpower  authorization  and  documentation  files, 
there  must  be  a set  of  "base  case"  data  from  which 
to  compute  increments  and  decrements. 

While  files  developed  by  the  QRA  and  QRAO  systems  (paragraphs 
3.1.3  and  3.1.4)  may  be  of  considerable  value,  as  would  automated 
files  of  data  relating  to  manning  documents,  other  files 
providing  data  with  respect  to  specialization  (NEC,  NOBC)  within 
activities  may  also  need  to  be  developed,  as  well  as  files 
containing  civilian  manpower  authorization  data  and  relationships 
(equivalencies)  between  military  billet  definitions  and  civilian 
position  definitions. 

In  addition,  the  requirements  for  certain  interim 
applications  previously  defined129  are  considered  still  valid. 


129  NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974, 

"CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS)",  pp  69,  70 
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SECTION  5.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  conclusions  and  recommendations  presented  in  this 
section  identify  some  of  the  difficulties  associated  with  the 
development  of  ADP  support  for  NAMPS  and  suggest  actions  that 
could  be  taken  in  subsequent  phases  of  the  technical  analysis  of 
NAMPS. 

5.1  'Technical  Management -of  NAMPS  ADP  Development.  During  the 
review  of  the  various  documents  used  in  preparing  this  report,  it 
became  apparent  that  the  development  of  ADP  support  for  NAMPS 
must  be  coordinated  and  controlled  in  a way  that  clearly 
delineates  the  responsibilities  of  each  participating 
organization.  It  must  consider  the  ultimate  goals  and  objectives 
of  NAMPS,  the  feasibility  of  integrating  separately  developed 
components,  and  how  NAMPS  should  ultimately  be  used.  Reasons  for 
concluding  that  improved  developmental  coordination  is  needed  can 
be  found  in  the  following  examples: 

a.  While  the  1974  NAVCOSSACT  report  reflected  the 
probability  that  different  agencies  would  have  mutually 
exclusive  roles  in  the  development  of  ADP  support  for 
NAMPS,  documents  produced  by  some  of  those  agencies 
subsequent  to  the  1974  report  do  not  appear  to  recognize 
those  roles,  although  the  report  was  approved  by  Op-01 
and  widely  disseminated.  In  more  than  one  such  document 
the  publishing  agency  appears  to  assign  to  itself  the 
lead  role  in  NAMPS  development,  ignoring  roles 
supposedly  to  be  played  by  other  agencies. 

b.  As  a result  of  inadequate  staffing,  a lack  of  technical 
knowledge,  and  the  urgent  necessities  of  day-to-day 
operations,  the  Manpower  Analysis  & Systems  Development 
Branch  (Op-121)  has  had  difficulty  in  sustaining  a 
continuous  coordinated  effort  to  provide  technical 
management  of  the  development  of  ADP  support  for  NAMPS. 

c.  Individual  agencies  appear  to  have  independently 
initiated  developmental  efforts  that  apparently  have  not 
considered  or  been  coordinated  with  efforts  by  other 
agencies  or  the  overall  requirements  of  NAMPS.  Some 
efforts  appear  to  duplicate  other  efforts;  at  least  one 
effort  seems  to  offer  little  of  value  to  the  future 
development  of  NAMPS  ADP  support.  For  example,  much  of 
the  results  of  the  NPRDC  study  effort  devoted  to  the 
analysis  of  manpower  planning  covers  ground  covered 


65 


before  and  may  prove  to  have  only  historical  interest, 
contributing  little  to  the  development  of  NAMPS. 

Measures  that  have  been  initiated  by  Op-01  since  this  study 
was  undertaken  but  which  have  not  yet  been  consummated  may 
alleviate  the  difficulties  described  above. 

5.2  The-Computer  Siting  Problem.  To  date,  the  development  of 
ADP  support  tor  bJAMPS  has  been  carried  out  on  a variety  of 
computers,  predominantly  IBM  and  UNIVAC  equipment.  "Pieces"  of 
the  NAMPS  ADP  support  currently  exist  on  UNIVAC  equipment  at 
NAVCOSSACT  (Washington  Navy  Yard)  , on  the  IBM  360/370  complex  at 
the  National  Institutes  of  Health  (NIH)  on  a rental  basis,  and  on 
an  IBM  360/65  at  the  Bureau  of  Naval  Personnel  (Bupers)  , 
Arlington,  Virginia.  The  NIH  computer  complex  is  not  considered 
a "secure"  site  and  cannot  be  used  for  classified  data,  but  both 
other  sites  are  "secure"  and  do  process  classified  data.  The 
Navy-owned  sites  are  currently  operating  at  close  to  saturation 
level . 


The  "scenario"  set  forth  in  Section  2 of  this  report 
requires  remote  terminal  access  to  automated  data  files  and  data 
processing  computer  programs  the  prototypes  for  which  are  spread 
among  tne  different  sites.  In  order  to  make  the  data  and 
computer  programs  accessible  for  demand-mode  processing,  one  of 
two  approaches  should  be  considered: 

a.  All  data  files  and  computer  programs  needed  to  support 
the  NAMPS  "scenario"  described  in  Section  2 must  be  made 
available  at  a single  secure  computer  site  accessible  by 
secure  remote  terminals  and  capable  of  holding  all 
needed  ADP  components. 

b.  Dynamic  access  to  data  files  and  computer  programs 
located  at  different  computer  sites  must  be  provided  by 
a data  commmunications  network  such  as  AUTODIN  II, 
currently  under  development.130 

A third  alternative  of  having  some  of  the  data  files  and  computer 
programs  accessible  through  one  terminal  and  others  accessible 
through  a different  terminal,  with  transfer  of  data  between 
computer  sites  accomplished  with  a transportable  machine-readable 
medium  (magnetic  tape  or  punched  cards)  , is  feasible  but 
obviously  degrades  the  responsiveness  and  reaction  capabilities 
of  NAMPS. 


130  Draft  NAVCOSSACT  Document  No.  84C049,  TR-01 , October  1975, 
"Implementation  of  AUTODIN  II  Phase  I within  the  Navy, 
Feasibility  Study" 
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The  first  alternative  is  accompanied  by  numerous  problems  of 
equipment  procurement,  conversion  of  data  files  and  computer 
programs,  and  actual  site  location.  It  is  assumed  that  current 
computer  equipment  configurations  at  available  sites  are 
inadequate  to  cope  with  the  volume  of  data  and  computer  usage 
that  would  be  required  under  NAMPS,  and  there  are  known 
incompatibilities  among  data  files  and  computer  programs  that 
have  already  been  developed  on  UNIVAC  and  IBM  equipment, 
presenting  the  problem  of  program  and  data  file  redesign  during  a 
substantial  conversion  effort. 

The  second  alternative  is  accompanied  by  a large  number  of 
"unknowns",  such  as  feasibility,  date  of  availability,  cost 
effectiveness,  etc. 

It  would  appear  that  a separate  study  of  this  problem  needs 
to  be  completed  at  an  early  date.  The  study  should  consider  all 
the  pros  and  cons  of  the  different  approaches,  evaluate  the  cost 
effectiveness  of  each,  and  present  a recommended  solution  that  is 
viable  within  the  NAMPS  concepts. 

5; 3 1 The* "Suppor  t - Tail* • Problem.  The  question  of  how  best  to 
derive  the  requirements  tor  support  capabilities  based  on  the 
ROCs  and  POEs  for  units  of  the  Operating  Forces  has  been 
addressed  but  not  answered.  The  use  of  an  input-output  model  has 
been  explored  in  pilot  studies  (see  paragraph  3.5.2),  but  some  of 
the  potential  difficulties  associated  with  this  type  of  model 
were  alluded  to  in  the  NPRDC  study  of  manpower  planning  (see 
paragraph  3.4).  "It  stands  to  reason  that  the  support 
sectors. . .exist  to  support  the  Operating  Forces ...  [and]  ..  .a 
change  in  the  make-up  or  level  of  Operating  Forces  should  be 
translatable  to  effects  on  the  support  sectors. . .The  input/output 
approach  seems  to  present  great  promise  for  solving  the 
technological  aspects  of  the  linkage  problem ...  However , the 
identification  of  all  of  the  necessary  linkages  and... 
data  flows  [representing]  the  volumes  of  supply  and  demand 
traveling  over  these  linkages  is  a massive  undertaking... 

The  linkages  identified  for  the  various  support  sectors  must  be 
integrated  at  some  level  of  detail  and  coupled  with  an 
appropriate  interactive  management  interface  capability... 
[requiring]  consideration  of  response  time,  format,  flexibility  . 
of  access  and  so  forth  that  is  implicit  in  the  manner  in  which 
management  must  use  its  information  resources...".131 


131  Draft  NPRDC  report,  Aprii  1975,  "An  Analysis  of  the  Navy 
Manpower  Planning  and  Programming  System"  , pp  229-231 
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The  pilot  studies  of  input-output  modelling  as  a solution  to 
this  problem  used  a wide  array  of  disparate  input  data  from 
source  documents  that  do  not  appear  to  be  automated.  To  support 
that  approach  to  data  collection  for  an  all-Navy  system  would 
appear  to  be  a very  costly  undertaking.  Secondly,  the  studies 
used  different  approaches  for  different  types  of  support 
activities.  This  implies  the  need  for  a wide  range  of 
input-output  models  each  tailored  to  a specific  type  of  support 
activity,  a questionable  solution.  To  be  successful  in 
supporting  the  NAMPS  scenario  outlined  in  Section  2,  a model  for 
the  derivation  of  support  requirements  from  required  capabilities 
of  the  Operating  Forces  must  be  simple,  easily  supported  with 
available  automated  data  sources,  and  applicable  to  all  types  of 
support  activities. 

Further  study  of  this  problem  and  various  alternative 
solutions  appears  to  be  a necessity.  Such  a study  should  not 
concentrate  on  the  feasibility  of  a single  solution,  such  as 
input-output  modelling,  but  should  consider  and  present  the  pros 
and  cons  of  other  possibilities.  At  least  two  other  areas  tor 
investigation  appear  worthy  of  consideration: 

a.  Examination  of  the  methodology  used  in  the  Long  Range 

Planning  System  (LRPS)  of  the  Naval  Sea  Systems  Command, 
cited  in  the  NPRDC  study. 132 


b.  Correlation  (by  computer)  of  RFCs  for  shore  activities 
(automated  in  the  SHOROC  system  and  available  in  the 
NMRS)  with  ROCs  and  POEs  of  ships  and  other  fleet  units 
(also  automated  in  the  NMRS)  to  determine  if  viable 
relationship  factors  can  be  derived. 

5.4~  The ‘Fleet’ Support  Network  Problem . In  considering  the  fleet 
support  proolem  area,  the  1^74  NAVCOSSACT  report  differentiated 
between  the  development  of  support  requirements  based  on  ROCs  and 
POEs  for  activities  of  the  Operating  Forces  and  the  assignment  of 
requirements  to  specific  shore  activities . 133  The  more  recent 
NPRDC  studies  do  not  make  the  distinction  but  seem  to  consider 


132  Ibid,  p 230 

133  NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974, 
"CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS)",  pp  38-43 
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both  aspects  of  the  problem  as  a single  entity,  leaving  the 
question  of  which  activity  performs  what  support  functions  for 
which  fleet  units  tor  later  study. 

The  fact  is  that  the  home  ports  and  home  stations  of  fleet 
activities  are  constantly  being  chaYiged.  Shore  installations  are 
phased  out  and  functions  and  responsibilities  transferred  to 
other  installations.  So  far  as  is  known,  this  constant  ebb  and 
flow  of  work  load,  occasioned  by  policy  decisions  made  in 
Washington,  is  not  recorded  in  any  automated  data  base  except  as 
unrelated  fragments  of  information.  The  effects  of  this  type  of 
workload  shift  may  not  become  apparent  to  the  shore  installations 
until  some  time  after  the  reass iqnmen ts  are  effective.  If 
manpower  planners  are  to  keep  abreast  of  the  changes  in  workload 
at  shore  installations  and  be  able  to  assess  the  impacts  of 
shifting  workloads  on  manpower  requirements,  there  must  be  an  » 
automated  data  system  that  shows  the  functional  interdependencies 
of  shore  activities  that  provide  fleet  support  through  the  home 
ports  and  home  stations  (the  "support  network");  and  this  data 
system  must  be  maintained  with  periodic  updates. 

While  the  Activity  Reference  Pile  described  in  paragraph 
3.1.1  does  record  recent  and  projected  changes  in  home  ports  and 
home  stations  of  fleet  units,  the  available  data  does  not  extend 
into  the  "support  network"  beyond  the  home  port  identifications. 
It  cannot  be  determined,  for  example,  which  shore  activities 
provide  specific  support  functions  for  fleet  units  whose  home 
port  is  Norfolk.  Conversely,  the  data  in  the  SHOROC  system 
(paragraph  3.1.2)  does  not  include  identifications  of  activities 
that  benefit  from  services  provided. 

It  seems  apparent  that  an  in-depth  study  of  this  problem  is 
required.  Existing  data  systems  of  the  systems  commands  and 
other  agencies  should  be  examined  to  see  what  useful  data  is 
already  recorded;  a specific  file  that  should  be  examined  is  the 
Master  Activity  General  Information  and  Control  (MAGIC)  file 
maintained  by  the  Systems  Division  (Code  (ill)  of  the  Naval 
Facilities  Engineering  Command  (NAVPAC) . The  study  should 
consider  the  pros  and  cons  of  incorporating  into  the  ARF  more 
data  available  in  automated  systems  not  currently  used  by  the 
ARF;  of  collecting  “support  network"  data  with  which  to  build  a 
new  automated  data  base  for  that  purpose  alone;  and  of  such  other 
possible  solutions  as  may  present  themselves. 

5i5 • 1 Sponsorship  Network  Problem.  The  NAMPS  "operating  scenario" 
descr ibed  in  Section  2 places  considerable  emphasis  on  the  roles 
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played  by  various  types  of  sponsors  (see  also  Figures  2-02,  2-03, 
and  2-04).  In  one  of  the  NPKDC  study  documentsl34  the  various 
interactions  and  interrelationships  have  been  graphically 
depicted  (Figures  5-01,  5-02,  5-03).  The  problem  which  this 
complex  network  of  sponsors  raises  for  the  development  of  ADP 
support  of  the  NAMPS  is  that  automated  definition  of  this 
“sponsorship  network"  does  not  exist.  Furthermore,  as  the  charts 
clearly  show,  the  identification  of  sponsors  does  not  extend 
below  the  DCNO/DMSO  level  into  the  staff  organizations 
themselves.  For  example,  in  Figure  5-02  the  DCNO,  Logistics 
(Op-04),  is  identified  in  four  different  subordinate  "boxes", 
implying  input  from  four  different  staff  offices,  but  these  staff 
offices  are  not  identified. 

It  is  recommended  that  the  problem  of  how  to  automate  the 
sponsorship  network,  how  specific  the  identification  of 
individual  sponsor  offices  should  be,  and  how  the  automated 
sponsorship  network  should  be  integrated  into  the  NAMPS  be  made 
the  subject  of  a separate  study. 

5.6  Other  Problem  Areas.  With  the  exception  of  the  problems 
described  in  paragrapns  5.1  and  5.5  above,  the  problem  areas 
discussed  in  this  section  were  previously  identified  in  the  1974 
NAVCOSSACT  report,135  and  many  of  the  questions  raised  in  that 
report  remain  unanswered.  In  addition , the  earlier  report  also 
discussed  other  problems  not  addressed  in  this  report  because 
apparently  no  action  has  been  taken.  Specifically,  the  other 
problem  areas  requiring  further  study  include: 

a.  How  to  derive  and  apply  manpower  costs. 

b.  How  to  develop  and  apply  factors  representing  future 
technological  improvements. 

c.  How  to  develop  and  apply  factors  representing  changes  in 
Navy  facilities. 

d.  How  to  develop  and  apply  "feedback"  data  from  various 
points  in  the  NAMPS  process. 

e.  How  to  integrate  civilian  manpower  planning  data  with 
military  manpower  planning  data. 


134  NPRDC  report  TR  75-19,  October  1974,  "Navy  Manpower  Planning 
and  Programming:  Basis  for  Systems  Examination" 

135  NAVCOSSACT  Document  No.  53D109,  TR-01,  September  1974, 
"CNOCOM/MIS  Support  for  the  Navy  Manpower  Planning  System 
(NAMPS)",  pp  72-77 
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FIGURE  5-02.  Support  of  One  Mission  Sponsor  by  Various 
Resource  Sponsors  (by  Program  Element) 
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vhc./jjct  unnunsT  ■ 

1-  Project  Request  Code:  53D109A 

2-  Project  Keene;. t T i t ? o : Technical  Analysis  of  the  Navy 

Ma npower  Planning  System  (NAMPS) , Phase  X 

3.  Objectives: 

a*  The  long-range  objectives  of  the  entire  series  of  efforts 
that  will  make  up  the  complete  study  of  ADP  applications  for 
NAMPS  are : 

(1)  To  determine  uh;  t ADP  applications  will  be  required 
to  support  the  operating  scenario  for  using  NAIlPS. 

(2)  To  determine  the  feasibility  of  developing  those 
ADP  applications  which  should  be  provided  by  the  Chief  of  Naval 
Operations  Command/Kanagement  information  System  (CMOCOM/NIS) . 

(3)  To  determine  the  shortfalls  of  current  plans  for 
developing  ADP  support  for  NAMPS. 

b.  The  limited,  short-range  objective  of  Phase  I of  the  study 
is  to  determine  what  the  subsequent  phases  of  the  study  will  be  based 
on  a description  of  the  MAiiPS  operating  scenario  and  a review  or 
on-going  efforts. 

4.  Concept  of  Operations : 

a.  Phase  I of  the  study  will  include  the  development  of  an 
operating  scenario  describing  how  the  N. .MPS  concepts  will  be 
employed  and  how  AD  I'  would  be  used  to  support  that  scenario; 
a review  of  documentation  describing  on-going  and  planned  NAMPS 
projects,  supplemented  by  a limited  number  of  interviews  to  obtain 
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a better  understanding  of  any  points  needing  clarification;  and 
preparation  of  rocoi.unei  dations  with  nspcct  to  subsequent  study 
efiorts  and,  where  pos tibia,  specific  AD!  applications  v;hich 

should  be  developed  under  CNOCOM/MIS.  . 

» _ y ' ♦ 
b.  Subsequent  phases  will  pursue  specific  areas  of  study 

identified  in  Phase  X,  with  tie  ultimata  goal  of  developing  a 

complete  technical  analysis  and  determination  of  reasibility  for 

providing  ADP  support  for  NAMPS.  

5.  Ts  sks. 

a.  Assist  the  Manpower  Analysis  & Systems  Development  Branch 
(Op-121)  in  developing  a detailed  operating  scenario  for  NAMPS 
and  the  use  of  ADP. 

b.  Review  available  documentation  describing  on-going  NAMPS 

'piojects.  • . . 

c Conduct  such  interviews  as  may  be  necessary  to  supplement 
ai  d c .arify  document  review'.  \11  inter- -iews  w:  11  be  conducted  in 
the  Wishington  area. 

d.  Identify  and  disc,  ibe  spe>  ific  tud/  e ffo.rts  which  should 
be  pursutd  in  subsequent  ; has<  of  the  f udy. 

e.  l.herc  possible.-,  i<  ent.  fy  nd  di.tcrihe  specific  ADP  appli- 
cations which  should  L i dt  vel<  ped  under  CN020M/MIS  to  support  the 
NAMPS,  relating  these  application.-;  to  s >ecific  study  areas. 
Descriptions  will  be  limited  to  o ijecti  -cs,  basic  functions,  and 
interfaces  with  otlier  ADI’  npp!  ications. 

f.  Document,  in  a Technical  Report,  the  r :sults  of  the 


Phase  I study  effort. 
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SOURCES  - 


ADP  - 


GLOSSARY  OF  TERMS  AND  ACRONYMS 


a.  Department  of  the  Navy  Programming 
Manual,  5 June  1971,  as  amended. 

b.  OPNAVINST  3501.33,  30  June  1972, 
"Required  Operational  Caoabilities 
Statement  (ROC)  and  Projected 
Operational  Environment  (POE)  ; 
Instructions  for  Preparation  of". 

c.  OPNAVNOTE  5310,  1 February  1974, 
"Shore  Requirements,  Standards,  and 
Manpower  Planning  System 
(SHORSTAMPS) " . 

d.  Op-901  memo  of  2 September  1975, 
POM-78-1,  ser  901/51352,  subject: 
"Program  Objectives  Memorandum 
Procedures  for  FY-78  (POM-78)". 

Automated  Data  Processing. 


ADS  - Automated  Data  System. 

ADSTAP  - Advancement,  Strength  and  Training  Planning 

’ Program.  See  paragraph  3.2.1. 

APPROPRIATION  SPONSOR-  A DCSO  or  DMSO  "charged  with  supervisory 
responsibility  over  an  appropriation"  (source  d)  . 
See  paragraph  2.2.1. 

ARF  - Activity  Reference  File.  See  paragraph  3.3.1. 

BASE  CASE  - A set  of  data  as  of  a given  point  in  time,  used  as 
~ a point  of  reference  for  subsequent  changes  to 

produce  alternative  proposals  ("notional"  files, 
q.v. ) . 

BILCO  - Billet/Position  Converter  and  Optimizer.  Formerly 

part  of  NMRS  (q.v.). 

BILDER  - Billet  Derivation,  part  of  NMRS  (q.v..).  See 

paragraph  3.3.4. 
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BUPERS  - 
CEB  - 
CNO  - 


Bureau  of  Naval  Personnel. 
CNO  Executive  Board. 

Chief  of  Naval  Operations. 


CNOCOM/MIS  - Chief  of  Naval  Operations  Command/Management 
Information  System. 


CPAM  - 
CPFG  - 
CPPG  - 
CULPRIT  - 
DBMS  - 
DCNO  - 
DIP  - 
DMSO  - 
POD  - 
ERP  - 
FAST  - 


CNO  Program  Analysis  Memorandum. 

CNO  Program  and  Fiscal  Guidance. 

CNO  Policy  and  Planning  Guidance. 

Commercial  report  generator  used  by  NMRS  (q.v.) 

Data  Base  Management  System. 

Deputy  Chief  of  Naval  Operations. 

Document  Input  Processor,  part  of  NMRS  (q.v.). 

Director  of  a Major  Staff  Office  (in  OPNAV) . 

Department  of  Defense. 

Enlisted  Requirements  Plan. 

(Enlisted)  Force  Analysis  and  Simulation 
Technique.  A computer  model  that  is  part  of 
ADSTAP  (q.v.).  See  paragraph  3.2.3. 


FORCE/FUNCTION  SPONSOR  - See  Resource  Sponsor. 


FYDP  - 
IBM  - 
I DMS  - 

IMAP  - 


Five  Year  Defense  proqram. 

Internationa]  Business  Machines. 

Integrated  Data  Management  System,  a 
commercial  DBMS  used  by  NMRS  (q.v.). 

Interactive  Manpower  Analysis  Proqram. 
See  paragraph  3.5.1. 


LSR  - 


Logistic  Support  Requirements  (system). 
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MANPOWER  DOCUMENT  (formerly  HANNING  DOCUMENT)  - A documentation 
of  the  manpower  required  for  a~given  activity  or 
type  of  activity  derived  by  the  application  of 
staffing  standards  to  statements  of  required 
capabilities,  as  modified  by  statements  of 
operational  environment  (for  Ship  and  Squadron 
Manpower  Documents) . 

MAPMIS  - Manpower  and  Personnel  Management  Information 

System. 

MARP  - Manpower  Requirements  Plan. 

MAP.RCS  - Manpower  Requirements  and  Resources  Control  System. 

MINI— NAMPS  - A contractor-produced  system  used  during  POM-77  and 
POM-78  (see  paragraph  3.2). 

MISSION  SPONSOR  - A DCNO  or  DMSO  "charqed  with  responsibility 
For  developing  overall  goals,  objectives, 
rationale,  justification  and  resource  requirements 
(including  manpower  , support  and  training)  for  a 
specified  mission  area"  (source  d)  . 

MPN  - Military  Pay,  Navy. 

MRCP  - Manpower  Resources  Coordinating  Panel. 

MRM  - Manpower  Reference  Model.  Part  of  NAMPS  (q.v.). 

MRP  - Mission,  ROC,  POE  Subsystem  of  NMRS  (q.v.). 

NAMPS  - Navy  Manpower  planning  System.  See  paragraph  2.1. 

NARM  - Navy  Resources  Model  . See  paragraph  3.2.3. 

NAVCOSSACT  - Naval  Command  Systems  Support  Activity. 

NAVMMACLANT  - Navy  Manpower  and  Material  Analysis  Center, 

Atl antic . 

NAVMMACPAC  - Navy  Manpower  and  Material  Analysis  Center, 

Pacific. 

NCIS  - Navy  Cost  Information  System. 

NEC  - Navy  Enlisted  Classification. 
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NIH 


National  Institutes  of  Health 


NMRS  - Navy  Manpowec  Requirements  System 

(see  paragraph  3.3). 

NOBC  - Naval  Office  Billet  Code. 

NOTIONAL  FILE  - A set  of  data  representing  the  results 

of  proposed  modifications  of  or  changes  to  a 
"base  case"  (a.v. ) . 

Naval  Personnel  Research  and  Development 
Center  . 

Office  of  Civilian  Manpower  Management. 


Office  of  Naval  Research. 

Output  Generator;  part  of  NMRS  (a.v.). 


CNO  staff. 


Officer  Requirements  Plan. 

Office  of  the  Secretary  of  Defense. 

Operation  Sequence  Diagram,  a technique  for 
graphically  portraying  management  processes.  See 
paragraph  3.4. 

Program  Element. 

PLATFORM  SPONSOR  - A type  of  Resource  Sponsor  (q.v.). 

POE  - Projected  Operational  Environment.  A statement 

establishing  the  most  demanding  condition  of 
operation  for  which  a shio  or  aircraft  squadron 
must  be  manned  (source  b) . 


NPRDC  - 

OCMM  - 
ONR  - 
OP  GEN  - 
OPNAV  - 
ORP  - 
OSD  - 
OSD  - 

PE  - 


POM  - Program  Objectives  Memorandum. 

POM  CYCLE  - The  annual  sequence  of  actions  and  events  which 
result  in  the  production  of  the  POM  (a.v.). 

POM  PROCESS  - The  procedures  used  during  a POM  cycle. 
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PPBS  - Planning,  Programming,  and  Budgeting  System.  The 


process  tor  collecting  intelligence,  appraising  the 
threat,  developing  strategy  to  meet  the  threat,  and 
devising  force  levels  to  support  the  strategy; 
programming  weapons  systems,  manpower,  and  support 
over  a period  of  time  to  attain  the  force  levels; 
and  budgeting  annual,  allocations  of  funds  to 
procure  personnel  and  materials  so  as  to  carry  out 
the  programs  (source  a)  . 

PROGRAM  ELEMENT  SPONSOR  - A DCHO  or  DMSO  "responsible  for  force 

"composition,  funding  support,  and  programmed 

manpower  for  a specific  program  element"  (source 
a).  See  paragraph  2.2.1. 

PROGRAM  SPONSOR  - A DCNO  or  DMSO  "who,  by  organization  charter, 
is  responsible  for  determining  program  objectives, 
time-phasing  and  support  requirements,  and  for  * 
appraising  progress,  readiness  and  military  worth 
for  a given  weapon  system,  function,  or  task" 
(source  .a).  See  paragraph  2.2.1. 

PROGRAMMING  CYCLE  - The  annual  sequence  of  actions  and  events 

which  constitutes  tne  programming  phase  of  the  PPBS 
(g.v. ) . 

QRA  - Qualitative  Requirements  Application.  See 

paragraph  3.1.3.. 

QRAO  - Qualitative  Requirements  Application  for  Officers. 

See  paragraph  3.1.4. 

R&D  - Research  and  Development. 

RAP  - Readiness  Assessment  Program.  See  paragraph  3.5.1. 

RENLQUAL  - An  end-month  extract  from  the  MAPMIS  Enlisted 
Billet  File.  See  paragraph  3.2.3. 

RESOURCE  SPONSOR  - Formerly  referred  to  as  Force/Function 
sponsor.  A DCNO  or  DMSO  "responsible  for  an 
identifiable  aggregation  of  resources  which 
constitute  inputs  to  mission  accomplishment.  His 
responsibility  covers  interrelated  programs  or 
parts  of  programs  found  in  several  mission  areas" 
(source  d) . See  paragraph  2.2.1. 
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ROFFQUAL  - 


SAMPS  - 


Required  Functional  Capabilities.  Tasking  phrases 
analogous  to  statements  of  Required  Operational 
Capabilities  tor  ships  and  aircraft  squadrons  but 
applicable  to  shore  activities  (source  c) . 

Required  Operational  Capability.  A specific 
functional  requiremeht  which  must  be  performed  by  a 
ship,  aircraft  squadron  or  unit  in  support  of  its 
assigned  mission  under  a particular  degree  or 
condition  of  readiness  (source  b) . 

An  end-month  extract  from  the  MAPMIS  Officer  Billet 
File.  See  paragraph  3.2.3. 

Shore  Activity  Manpower  Planning  System  under 
OCMM.  See  paragraph  3.6.3. 


SECDEF  - 


SECNAV  - 


Secretary  of  Defense. 
^Secretary  of  the  Navy. 


S HQ ROC  - Shore  Required  Operational  Capabilities  (see 

paragraph  3.1.2.).  Part  of  SHORSTAMPS  (q.v.). 

SHORSTAMPS  - Shore  Requirements,  Standards  and  Manpower  Planning 
System. 


SMD  - 


SMIS  - 


SMORE  - 


SPP  - 


Ship  Manpower  Document. 

Ship  Management  Information  System. 

Ship  Mobility  and  Operational  Readiness 
Evaluation.  See  paragraph  3.5.1. 

Sponsors  Program  Proposals. 


STAFFING  STANDARDS  - Manpower  required  for  the  performance 

of  identified  tasks,  derived  by  the  application  of 
accepted  industrial  engineering  techniques  to  work 
measurement  data  collected  according  to  a 
predetermined  plan  (source  c)  . 

SUPPORT  “TAIL"  - Workload  requirements  generated  by 

operational  demands;  consists  of  ship-to-ship 
support  (e.g.,  underway  replenishment), 
ship- to-shore  support,  and  shor e-to-shore  support 
(also  referred  to  as  "support  on  support"). 


C-7 


TISA 


T-POM  - 
UIA  - 


Technique  for  Interactive  Systems  Analysis.  See 
paragraph  3.4. 

Tentative  POM  (q.v.). 

Unit  Identification  Application. 


UIC  - Unit  Identification  Code. 

WARFARE  SPONSOR  - Term  formerly  used  for  Platform  Sponsor 
(q.v.). 


